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-10 La presente invention conceme un precede et un dispositif de 

comnnunication d'information. 

Elle s'applique, en particulier. a un reseau a commutation 
asynchrone de paquets. permettant notamment d'interconnecter un petit nombre 
d'6quipements multimedia, tout en leur foumissant differentes qualites de service 
1 5 pour echanger des donnees. 

Le comportement d'un trafic de donnees genere par un equipement 
multimedia (ou application) peut s'inscrire dans deux classes de service 
principales, elles memes divis6es. chacune. en deux sous-classes. Ainsi le trafic 
peut etre soit elastique (il s'adapte facilement aux changements de conditions de 
20 transmission), soit temps reel. S'il est elastique. il peut soit etre de nature 
interactive, et done sensible au delai de transfert. soit correspondre a un transfer! 
massif d'un gros volume de donnees et done sensible a la bande passante. S'il 
s'agit d'un trafic temps reel, soit il est acceptable de perdre certains paquets 
d'information pour privilegier le delai de transmission, le trafic est alors appel6 
25 "d6terministe". soit il est preferable de disposer d'un debit moyen mais sans perte 
de donnees. le trafic est alors appel6 "garanti". 

Le trafic elastique correspond au trafic de type datagramme. Ce 
trafic est dit elastique car il est capable de s'adapter aux conditions de 
transmission sans pour autant perdre de son utilite. Un transfert de fichier pounra 
30 aussi bien s'executer via un chemin supportant un debit de 64 kilobit par seconde 
que via un chemin supportant un debit de 2 Megabit par seconde. Pour le trafic 



elastique. une premiere classe de base concerne le trafic genere par les 
applications interactives ou transactionnelles (comme une application de type 
client-serveur). et une seconde classe identifie les donnees vehiculees par bloc 
(comme le transfer! de fichiers). 

5 Les equipements generateurs d'un trafic temps reel requierent un 

service deterministe ou garanti. Pour le trafic deterministe, qui privilegie le respect 
d'une contrainte elevee en ce qui concerne le d6lai de transmission, {'application 
qualifie la bande passante dont elle suppose avoir besoin. ainsi que le delai 
maximal de transmission qu'elle peut accepter. Le reseau privilegie ce type de 

10 trafic mais se debarrasse des donnees pour lesquelles le delai ne peut etre 
respecte. II s'agit par exemple de transmission video (en cas de problemes de 
transmission, une image statique apparaTt). ou de systemes audio de qualite 
moyenne. 

Le service dit garanti se differencie du service deterministe par le fait 

15 que le reseau ne se debarrasse pas volontairement des donnees issues d'un 
trafic garanti mais que celui ci peut etre affecte d'un delai de transmission variable 
en fonction du trafic detemiiniste plus prioritaire ou au trafic garanti concurrent. II 
s'agit, par exemple. du trafic video haute definition (utilisant des techniques de 
compression), Dans ce cas. le reseau reserve la bande passante a I'application 

20 qui requiert un service garanti, mais pour gerer les problemes de gigue (en 
anglais "jitter) sur les donnees a la reception, I'application doit poss6der des 
capacites de stockage temporaires des donnees (de I'ordre de la seconde de 
trafic), afin de retablir le comportement original du trafic. 

La garantie de la qualite de service exigee par des applications 

25 concurrentes et de natures differentes passe par la resolution de problemes tels 
que la gestion des ressources et le controle de trafic. Les precedes S mettre en 
oeuvre doivent permettre au reseau de fonctionner de fagon optimale tout en 
foumissant une qualit§ de sen/ice acceptable aux differentes applicafions. Ce 
probleme a fait I'objet de nombreuses 6tudes pour les r6seaux a commutation de 

30 circuits et pour les reseaux ^ commutation de paquets. 
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Dans les reseaux a commutations de circuits, la solution connue 
consists a allouer a chaque connexion une bande passante constante (canal) 
pendant toute sa duree. Au prealable, une procedure d'acceptation d'appel 
permet au reseau de savoir s'il peut supporter I'appel. Dans le cas ou aucun canal 
n'est disponibie, Tappel est rejete. 

Dans les reseaux a commutation de paquets ou le trafic est, par 
definition, imprevisible. la nature variable des debits offre I'opportunite d'un 
partage statistique des ressources du reseau. Cette optimisation des ressources 
augmente, malheureusement, les risques de congestion. Ces reseaux peuvent 
etre vus comme une succession de files d'attente a capacite limitee dont 11 
convient de controler le remplissage afin d'eviter leur saturation, synonyme de 
perte de paquets. 

II est connu de controler le trafic par un mecanisme dit "de 
fenetrage" : lorsqu'un etat de saturation est d6tecte, le recepteur demande 
explicitement a la source de reduire son flux. On parte alors de regulation et de 
controle de flux. 

Aucune de ces approches n'est suffisante, la premiere parce qu'elle 
conduit a un gaspillage inevitable des ressources du reseau en allouant a la 
source une bande passante correspondant a son debit maximal et la seconde 
parce que le rapport du temps de propagation sur le temps de transmission 
augmente de maniere considerable lorsque les liaisons sont a tres haut d6bit. 
Dans les systemes de controle de flux par retroaction, entre Tinstant d'emission de 
la notification de congestion et Tinstant de sa reception par le noeud source, le 
trafic deja en transit dans le reseau peut etre considere comme definitivement 
perdu en raison de la congestion, a moins de disposer de memoires de grande 
capacite pour consen/er tous les paquets en transit pendant Tetat de congestion. 

Par consequent, pour la commutation rapide de paquets, les 
methodes de controle purement r6actives sont insuffisantes dans un 
environnement haut debit. La commutation n6cessite des m6canismes 6labores 
dans les 6quipements de commutation (noeuds intemriediaires du reseau) incluant 
des methodes preventives et des m6thodes reactives. La technologie ATM 



("Asynchronous Transfert Mode" ou mode de transfert asynchrone), propose des 
techniques de gestion de la qualite de service, et de controle de congestion 
basees sur des mecanismes elabores implement's au sein des equipements de 
commutation, Des exemples de tels mecanismes sont decrits dans les brevets US 
5.291,481 et US 5,313,454 qui illustrent aussi la complexity et le cout potentiel 
d'implementation de telles methodes. 

Ces methodes ne sont done pas adaptees a des reseaux 
comprenant un nombre plus restreint d'equipements a interconnecter ou le cout 
des moyens de communication ne doit pas etre trop eleve par rapport au cout des 
equipements ^ interconnecter. 

Des tentatives d'utilisation de commutateurs ATM embarques ont 
ete faltes, telles que celle decrite dans la these "Architecture distribuee temps reel 
fond6e sur ATM" de Jean-Frangois Guilaud (INPG). Cette these mentionne 
I'utilisation de la signalisation ATM classique afin de permettre la gestion des 
connexions, ce qui represente une implementation complexe. Cependant, la mise 
en oeuvre complete des mecanismes de gestion des connexions doit prevoir 
d'eviter la congestion, qui, afin de simplifier I'utilisation du commutateur, reposent 
sur une gestion locale des informations de charge et sur Tutilisation des files 
d'attente en sortie pour chaque commutateur. 

Le controle de flux strict, a la source, tel qu'il est decrit dans la 
these, prevoit Tutilisation d'un mode connecte uniquement, et verifie le non 
depassement du transfert de donn6es par rapport a ce qui a ete prevu lors de 
I'etablissement de la connexion correspondante. Cela peut done engendrer une 
mauvaise utilisation des ressources reseau ainsi qu'un manque de flexibilite du 
systeme. 

Par ailleurs, il n'est envisage aucun moyen simple pour reagir au 
probleme de congestion si ce n'est en se reposant sur les solutions decrites 
precedemment. propre a {'utilisation de I'ATM. mais qui demeurent des solutions 
complexes. 

De plus, Tutilisation d'une dimension de paquet fixe, conform6ment 
^ TATM, engendre une perte fixe du d6bit utile par lien du r6seau disponible. En 



revanche, une taille de paquet variable en fonction de la charge du reseau pemnet 
d'optimiser le debit utile. Les techniques de controle de la taille des paquets ont 
deja ete testees surdes architectures r6seau de type bus ou anneau. 

La commutation asynchrone de paquets, telle que decrlte dans la 
5 norme IEEE-P1355, est basee sur une technologie de commutation (matrice de 
commutation non bloquante permettant plusleurs chemins simultanes) a falble 
coOt de realisation en ce qui concerne le commutateur. En effet, le commutateur 
en question n'utillse qu'un minimum de ressources pour effectuer la commutation 
d'un paquet a partir d'un port d'entree vers un port de sortie. Le transfert d'un 
1 0 paquet au travers du commutateur a lieu d6s que le commutateur a connalssance 
des informations de commutation du dit paquet (en-tete de paquet) sans attendre 
la complete reception de toutes les donn§es du paquet. II n'y a done aucune 
gestion de file d'attente ou de priorite dans les noeuds interm6diaires du chemin. 

Par ailleurs, afin de regler les problemes de contention d'acces ^ un 
15 port d'entree (respectivement vers un port de sortie) du commutateur, lorsque 
plusleurs paquets sont a priori destines k transiter via ce port d'entrde 
(respectivement de sortie), un mecanisme de controle de flux au niveau du lien 
est implemente, n'autorisant une source a transmettre des donnees sur la ligne de 
transmission que lorsqu'elle a obtenu I'autorisation de la part de la destination, 
20 c'est-a-dire lorsqu'un groupe de donnees pr§c6demment 6mlses par la source ont 
§te acquittees par la destination. 

Cependant, la commutation asynchrone de paquets, telle que 
connue dans I'etat de la technique, si elle lalsse envisager des couts 
d'implementation attractifs. ne prevoit pas de garantir differentes qualit^s de 
25 service pour les trafics concunrents au sein d'un mSme r§seau. 

Les technologies de type bus s§rie proposent une alternative d 
I'utilisation de la commutation de paquets pour interconnecter des p6riph6riques ^ 
moindre cout. En effet, les mecanismes mis en oeuvre pour partager les 
ressources se trouvent simplifies du fait de I'unicit^ de la ressources principales, 
30 en I'occun-ence le medium de communication. Cette simplicity implique aussi 



rinconvenient d'une bande passante limitee : la bande passante moyenne 
disponible par terminal diminue en fonction du nombre de terminaux connectes. 

Certaines technologies bus serie. telles que celle normalisee par 
riEEE, reference PI 394, definie pour rinterconnexion d'equipements multimedia, 
supportent le transfert des donnees selon principalement deux classes de sen/ice 
en mettant en oeuvre une architecture logique de type bus. Des mecanismes sont 
done necessaires pour arbitrer I'acces au bus et organiser le transfert des 
donnees. Cette technologie de bus s6rie prevoit un mecanisme de reservation de 
ressources. II permet. d'une part, la transmission de donnees dite isochrone, 
comprenant une phase de reservation, et, d'autre part, la transmission de 
donnees dite asynchrone, sans phase de reservation. 

Le document US-A-4 ,91 4,650 decrit une m§thode pour organiser 
la transmission de donn§es en provenance de files d'attente differentes et pour 
y inserer un trafic ultra prioritaire (de type signalisation) en provenance d'une 
troisieme file d'attente, ainsi que des mecanismes pour reagir au probleme de 
congestion dans les files d'attente associees a chaque type de donn§es. II ne 
propose pas de solution pour limiter les pertes d'information dues a des 
problemes de congestion et done pour garantir differentes qualites de service. 

Le document US-A-5, 62 1.898 illustre un mecanisme pour 
organiser la transmission des donn6es sur un bus conforme aux specifications 
IEEE-PI 394. II d6crit ainsi le sequencement des transmissions de paquets, 
associe a differentes files d'attente ainsi que les mecanismes de controle 
d'acces au bus permettant de prendre en compte la bande passante disponible 
pour la transmission de paquets suppl§mentaires. 

L'invention vise a permettre, sur un reseau a commutation de 
paquets, le s6quencement des transmissions de paquets a la source, selon 
differentes priorit6s, en fonction, d'une part, de la charge estimee du r6seau (en 
maintenant ^ jour une table de charge pour tout le trafic connecte) et, d'autre part, 
en fonction de la charge effective du r6seau (contrdle de flux au niveau des liens). 

Dans son application a un r6seau commute, la pr§sente invention 

vise : 
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- a garantir un acces equitable aux ressources du reseau 
comprenant plusieurs equipements multimedias ; 

- a organiser le transfert de paquets afin que certains de ces 
paquets traversent le reseau avec un temps de latence inferieur a une valeur 

5 maximale garantie ; 

- a garantir. pour un groupe de paquets formant un flux, une valeur 
de bande passante determinee ; 

- ^ privilegier la transmission de certains paquets dont le contenu 
d§crit de I'infomriation dite "de controle", 

10 - a optimiser I'utilisation de la bande passante effective du reseau. 

- a detecter et a circonvenir les congestions du reseau. et 

- a affranchir les commutateurs des dispositifs de communication 
intermediaires de tout traitement concemant Torganisation du sequencement des 
paquets. 

15 A cet effet, la presente invention vise un procede de 

communication sur un reseau comportant des dispositifs de communication, 
chaque dispositif de communication etant adapte a determiner, pour chaque 
information qu'il a a transmettre. [e chemin a lui faire suiyre sur le reseau et un 
mode de transmission, connecte ou non, caracterise en ce qu'il comporte : 

20 - pour chaque dispositif de communication qui doit effectuer une 

transmission en mode connecte, une operation d'information au cours de 
laquelle ledit dispositif de communication diffuse, a destination de tous les 
autres dispositifs de communication du reseau, une information representative 
de la bande passante n6cessaire pour ladite transmission en mode connects, et 

25 - une operation d'attribution de bande passante. au cours de 

laquelle on attribue. d'une part, aux transmissions en mode connects, la bande 
passante qui leur est n6cessaire et, d'autre part, toute ou partie de la bande 
passante disponible a chaque transmission a effectuer en mode non connects. 
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Ainsi, tous les dispositifs de communication du reseau sont 
immediatement informes de chaque connexion et des ressources du reseau qui 

lui sont affectees. 

Avant d'effectuer la transmission d'un paquet en mode non 
5 connecte, chacun des dispositifs de communication suscepttbles de le faire, 
peut verifier que chacun des liens, ou segments, du chemin que va suivre ce 
paquet est disponible pour la transmission de ce paquet. Les engorgements 
peuvent ainsi etre 6vites. 

La regulation de la charge dediee au trafic en mode non connecte 
10 peut ainsi etre effectuee en fonction des fluctuations du trafic en mode connecte 
(temps r6el), ce qui permet d'optimiser en permanence rutillsation du r6seau et 
d'eviter les engorgements. 

Selon des caracteristiques particulieres, le proc§de de 
communication tel que succinctement expose ci-dessus comporte, pour un 
1 5 6tablissement de connexion : 

- effectuee par le dispositif de communication source destine a 
transmettre de I'information sur ledit chemin. une operation de transmission, a 
destination de chaque dispositif de communication place sur ledit chemin, appele 
"interm6diaire", d'une information representative de la bande passante necessaire 

20 pour ladite connexion, et 

- effectu6e par chaque dispositif de communication intermediaire sur 
ledit chemin, une operation de determination de disponibilite du lien menant au 
dispositif de communication suivant sur ledit chemin et. en cas d'indisponibilite, 
une operation de transmission ^ destination du dispositif de communication 

25 source d'une information representative de Tindisponibilite dudit chemin. 

Gr§ce ^ ces dispositions, avant d'etablir une connexion, on verifie 

que le r6seau peut supporter la charge potentielle associ6e S la connexion ^ 

etablir. En outre, cette verification est faite par chaque dispositif de communication 

place sur le chemin associe § cette connexion. 
30 Cette prise en compte de la charge estim6e revient a effectuer une 

estimation de la congestion du reseau. 



Selon d'autres caracteristiques particulieres, le procede de 
communication tel que succinctement expose ci-dessus comporte. pour chaque 
transmission dMnfomnation. une operation de controle de flux effectuee 
conformement a la norme IEEE 1355. par chacun des dispositifs de 
communication intemnediaires du chemin suivi par ladite information. 

Grace a ces dispositions, le procede selon rinvention implemente un 
controle de flux au niveau des liens, aussi bien pour le trafic connecte que pour le 
trafic non connecte. sur un reseau a commutation de paquet. Ces dispositions 
reviennent a effectuer un detection de la congestion du reseau. 

Selon d'autres caracteristiques particulieres, le procede tel que 
succinctement expose ci-dessus comporte : 

- pour chaque dispositif de communication du reseau, a la suite de 
chaque operation d'information, une operation de determination de la bande 
passante disponible sur chaque lien, en prenant en compte lesdites 
informations, et 

- pour chaque dispositif de communication dit "source" qui doit 
effectuer une transmission en mode non connecte a destination d'un dispositif 
de communication destinataire : 

• une operation de determination de dispdnibilite de chemin 
pour une transmission en mode non connecte, au cours 
de laquelle on determine si au moins une chemin allant 
dudit dispositif de communication source audit dispositif 
de communication destinataire est au moins partiellement 
disponible pour ladite transmission, 

• et, dans Taffirmative, une operation de transmission sur 
ledit chemin, en mode non connecte. 

Grace a ces dispositions, plusieurs chemins peuvent etre utilises 
par les transmissions en mode non connects, en fonction de la charge du 
reseau. 

Selon d'autres caracteristiques particulieres, le proc6d6 de 
communication tel que succinctement expose ci-dessus comporte une 



operation de la transmission conformation prenant en compte plusieurs niveaux 
de priorite, et un niveau de priorite est affecte a la transmission en mode non 
connecte. 

Grace ^ ces dispositions, tout le trafic en mode non connecte est 
5 transmis avec le meme niveau de priorite, ce qui garantit un-acces equitable 
pour tous les dispositifs de communication du reseau. 

Selon d'autres caracteristiques particulieres, au cours de 
I'operation d'attribution de bande passante, la bande passante associee au 
niveau de priorite correspondant au mode non connecte varie en fonction d'une 
10 duree n'ayant donne lieu a aucune transmission, 

Le precede de invention permet ainsi d'augmenter la bande 
passante allouee aux transmissions en mode non connecte. lorsque la duree 
n'ayant donne lieu a aucune transmission augmente, ce qui est signe d'une 
absence de congestion du reseau. 
-15 Selon d'autres caracteristiques particulieres, au cours de I'operation 

d'attribution de bande passante, la bande passante associee au niveau de 
priorite correspondant au mode non connecte varie en fonction d'un nombre de 
paquets non transmis pendant une dur6e predeterminee. 

Le precede de I'lnvention permet ainsi de reduire la bande 
20 passante allouee aux transmissions en mode non connecte. lorsque le nombre 
de paquets non transmis augmente, ce qui est signe d'une congestion du 
r6seau. 

Selon d'autres caracteristiques particulieres, a cheque niveau de 
priorite est associe une liste de canaux virtuels, successivement mis en oeuvre, 

25 lesdits canaux virtuels sent associes au trafic sortant. 

Gr§ce S ces dispositions, le sequencement des Emissions est 
effectu6 sur le trafic sortant et il n'y a done pas de gestion de ce trafic par les 
dispositifs de communication interm§diaires, ce qui simplifie le fonctionnement 
du r6seau et le rend plus efficace. 

30 Selon d'autres caract6ristiques particulieres, le proc6d6 tel que 

succinctement expos§ ci-dessus comporte une operation de determination de 
paramStres de transmission, au cours de laquelle on determine : 
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- une dimension de paquets transmis sur ledit reseau. ladite 
operation prenant en connpte la charge sur ledit reseau. 

- un nombre de paquets a emettre sur ledit reseau, ladite 
operation prenant en compte la charge sur ledit reseau, et/ou 

- une duree disponible pour emettre les paquets restant a emettre 
sur ledit reseau, ladite operation prenant en compte la charge sur ledit reseau. 

Ainsi. la bande passante peut etre repartie au mieux (c'est-a-dire 
efficacement et equitablement). 

Selon des caracteristiques particulieres, Toperation de 
determination de parametres de transmission a lieu pour chaque dispositif de 
communication, canal virtuel par canal virtuel. 

Ainsi, les parametres de transmission peuvent dependre du 
chemin utilise. 

Selon des caracteristiques particulieres. ladite operation de 
determination de parametres de transmission est effectuee lors de Toperation 
d'information. 

Grace a ces dispositions, la mise a jour des parametres peut avoir 
lieu de maniere dynamique et immediate et le reseau peut done etre reactif aux 
variations des contraintes de charge. 

Selon d'autres caracteristiques particulieres, pour le trafic garanti, 
rinformation non transmise durant un intervalle de temps predetermine, est 
conservee pour etre transmise durant Pintervalle de temps suivant. 

Grace a ces dispositions, des risques de congestion sont evit6s. 

Selon un deuxieme aspect, la presente invention vise un dispositif 
de communication sur un reseau comportant des dispositifs de communication, 
chaque dispositif de communication etant adapte a determiner, pour chaque 
information qu'il a a transmettre, un chemin a lui faire suivre et un mode de 
transmission, connects ou non, caract6ris6 en ce quMI comporte : 

- un moyen d'information adapte, pour chaque transmission en 
mode connecte, a diffuser, a destination de tous les autres dispositifs de 
communication du reseau, une information representative de la bande passante 
necessaire pour ladite transmission en mode connecte, et 
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- un moyen d*attribution de bande passante. adapte a attribuer, 
d'une part, aux transmissions en mode cxDnnecte, la bande passante qui lui est 
necessaire et, d'autre part, tout ou partie de la bande passante disponible a 
chaque transmission a effectuer en mode non connecte. 

L'invention vise aussi un ordinateur. une camera, un telecopieur, 
un appareil photographique, un televiseur, une imprimante, un scanner et un 
lecteur audio/video, caracterises en ce qu'ils comportent un dispositif tel que 
succinctement expose ci-dessus. 

Uinvention vise aussi : 

- un moyen de stockage d'informations lisible par un ordinateur ou 
un microprocesseur conservant des instructions d'un programme informatique 
caracterise en ce qu'il permet la mise en oeuvre du precede de Tinvention telle 
que succinctement exposee ci-dessus, et 

- un moyen de stockage d'informations amovible. partiellement ou 
totalement. et lisible par un ordinateur ou un microprocesseur conservant des 
instructions d'un programme informatique caracterise en ce qu'il permet la mise 
en oeuvre du procede de Tinvention telle que succinctement exposee ci-dessus. 

Les caracteristiques pr6ferentielles ou particulieres, et les 
avantages de ce dispositif, de cet ordinateur. de cette camera, de ce 
telecopieur. de cet appareil photographique. de ce televiseur. de cette 
imprimante, de ce scanner, de ce lecteur audio/video et de ces moyens de 
stockage d'information etant identiques a ceux du procede tel que 
succinctement expos6 ci-dessus, ces avantages ne sont pas rappeles ici. 

D'autres avantages et caracteristiques de Tinvention ressortiront 
de la description qui va suivre, faite en regard des dessins annexes dans 
lesquels : 

- la figure 1 represente un reseau de noeuds interconnectes, 

- la figure 2 represente un dispositif (ou «moyen») de 
communication selon la pr6sente invention, 

- la figure 3 represente des 6changes de messages intervenant 
entre un noeud source et un noeud destinataire pour v6hiculer d'une part un 
trafic connecte et, d'autre part, un trafic non connects, 
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- la figure 4 represente un organigramme mis en oeuvre par le 
moyen de communication du noeud dit "source" pour una transmission en 
mode connecte, 

- la figure 5 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "intermediaire" pour une transmission 
en mode connecte. 

- la figure 6 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "destinataire" pour une transmission 
en mode connecte. 

- la figure 7 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "voisin" pour une transmission en 
mode connecte, 

- la figure 8 represente un reseau sur lequel circuient des 
messages de controle destines a la gestion du mode connecte, 

- la figure 9 represente la structure de messages de controle 
destines a la gestion du mode connecte. 

- la figure 10 represente la structure de donnees d'une table de 
charge en memoire d'un moyen de communication. 

- la figure 11 represente ia structure de donnees d'une table de 
specifications et de priorites contenant des canaux virtuels reserves a la 
transmission en mode connecte. en memoire d'un moyen de communication, 

- la figure 12 represente un organigramme d'emission en modes 
connecte et non connecte d'un moyen de communication tel qu'illustre en figure 2, 

- la figure 13 represente un organigramme de detemiination, par le 
noeud source, de disponibilite de chemin pour Tetablissement d'une connexion, 
incorpore dans I'organigramme de la figure 4, 

- la figure 14 represente un organigramme de determination, par un 
noeud interm6diaire ou le noeud destinataire, de disponibilite de chemin pour 
Tetablissement d'une connexion, incorpor6 dans I'organigramme de la figure 5 ou 
6, et 
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la figure 15 represente un organigramme de determination, 
par un noeud voisin. de disponibilite de chemin pour Tetablissement d'une 
connexion, incorpore dans I'organigramme de la figure 7. 

Dans toute la presente demande les termes "dispositifs de 
communication " et "moyen de communication" ont la meme signification et 
d6signent les memes combinaisons de moyens objets de la presente invention. 

Le mode prefere de realisation gere trois classes de service 
sp6cifiques, deterministe (en mode connecte), garantie (en mode connecte) et 
elastique (en mode non connecte), sur un reseau a commutation de paquet. 

En figure 1, on observe cinq equipements multimedias 101 a 105 
d'un reseau a commutation de paquet 100, relies entre eux par six liens 106 a 
111. Chaque equipement multimedia comporte un moyen de communication 
112 et un moyen de traitement de donnees 113. Le moyen de communication 
112 permet au moyen de traitement 113 d'ouvrir une connexion dediee a un 
trafic connecte (trafic temps reel deterministe ou garanti) puis de generer ce 
trafic. ou bien de generer directement un trafic non connecte (trafic elastique). 

Lorsque Tequipement multimedia 101 envoie un paquet de 
donnees ^ I'equipement multimedia 105, par I'intermediaire des liens 108 et 
110, I'equipement 101 est un noeud "source". I'equipement 105 est un noeud 
"destinataire", I'equipement 102. par lequel transitent les donnees. est un noeud 
"intermediaire", tandis que les noeuds 103 et 104 sont des noeuds "voisins", 
aucune des donnees transmises ne transitant par Tun d'entre eux. 

Le mode de r6alisation decrit et represente concerne un reseau 
local compose de plusieurs noeuds interconnectes par des liens bidirectionnels 
rapides. Chaque noeud incorpore un commutateur non bloquant possedant une 
matrice de commutation a r6ception et Emission simultanees (en anglais "cut- 
through crossbar") et poss6de un certain nombre de ports externes auxquels 
peuvent etre raccord6s des liens. Dans un tel reseau, la route ou le chemin 
suivi par un paquet est une succession de liens, chacun des liens §tant d6fini 
par les deux noeuds qu'il rejoint. 
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La communication sur un tel reseau est dite "commut§e". Un 
exemple d'un tel reseau est donne par un systems utilisant des composants 
selon la norme IEEE 1355. 

En figure 2, on observe un schema bloc d'un moyen de 
5 communication 1 12 du reseau, comportant un composant commutateur/routeur 
209 couple a une unite centrale 206 (decomposee en deux entites 206A et 206 
B). 

Le composant commutateur/routeur 209, constitu6 d'un 
composant de la marque SGS-THOMSON (marque deposes), reference ST 
10 C104, comporte des ports physiques relies a un connecteur 230. et deux ports 
internes dont Tun est dedie au controle, relies a I'unite centrale 206 par 
rintermediaire de differents composants decrits ci-dessous. 

On observe ici que le composant commutateur/routeur 
susmentionne 209 ST CI 04 possede, en fait, trente-deux ports physiques en 
15 plus de deux ports de controle, seulement un port de controle et quelques ports 
physiques etant representes en figure 2. Des composants d'interface 213 et 
216 sont relies aux deux ports internes du composant commutateur/routeur 209 
et sont, chacun. bases sur un composant reference ST CI 01 et fabriqu6 sous la 
marque SGS-THOMSON. 

20 Le composant commutateur/routeur 209 et les composants 

d'interface 213 et 216 effectuent un codage conforme a la norme IEEE 1355. Le 
composant commutateur/routeur 209 est a architecture de type non bloquante. 

Des emetteur/recepteurs, non representes, plus connus sous leur 
denomination technique de langue anglaise " transceiver ", convertissent des 
25 signaux TTL, sur les ports physiques du composant commutateur/routeur 209 
en signaux differentiels sur le connecteur 230. 

Les emetteurs/r6cepteurs sont, par exemple. des composants de 
la marque AT&T (marque depos6e) r6f6renc6s 1 141 MK. 
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Le connecteur 230 est destine a etre relie a plusieurs connecteurs 
identiques incorpor6s a d'autres moyens de communication du reseau. lis sont 
de la marque deposee HARTING at de reference 2721-121-8000. 

Les composants d'interface 213 et 216 sont relies, par une liaison 
parallele, a une interface PCI 208. elle-meme reliee a un bus PCI 231. 
L'interface 208 est, par exemple. composee d'un circuit AMCC (marque 
deposee) S5933. Le bus PCI 231 est. en outre, relie : 

- a un composant d'interface 232. identique au composant 208. lui- 
meme relie au moyen de traitement 113 (figure 1) ; 

- ^ une interface de controle 203. par exemple constituee d'un 
composant 82439 HX de marque INTEL ©. lui-meme relie a un bus local d'unite 
centrale 206, comportant un microprocesseur 206A et une memoire cache 
statique 206B. et a une memoire dynamique 204 (constituee des deux entites 
204A et 204 B) ; et 

- a un composant d'interface 205. par exemple de reference 
82371 58 de marque INTEL ©, ce composant etant relie ^ un bus ISA qui relie 
un controleur ISA de peripheriques 233, a une memoire flash de systeme 
d'exploitation BIOS 234. a une horloge temps-r6el 235 et a une extension de 
memoire flash 236. 

L'architecture et les composants du moyen de communication 112 
sont bien connus de I'homme du metier des syst^mes informatiques et ils ne 
sont pas plus detaill6s ici. 

Pour une meilleure comprehension de la constitution du mode de 
realisation decrit et repr6sente. le lecteur est invite a consulter les notes 
d'utilisation des composants. notes fournies par leurs constnjcteurs respectifs. 

L'unit6 centrale de traitement CPU 206 est composee d'un 
microcontr6leur 206A de la marque d6posee INTEL et de reference PENTIUM 
(marque d6pos6e) avec 32 Mo de m6moire vive dynamique DRAM 204 ^ titre 
de memoire de travail, 256 Ko de m6moire statique cache 206B. 

On observe ici que I'expression "segment de memoire" utilis§e ci- 
dessous d6signe. dans chacune des m6moires, aussi bien une zone m6moire 
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de faible capacite (ne conservant que quelques donnees binaires). qu'une zone 
memoire de grande capacity (permettant de stocker un programme entier). 

La memoire vive 204A conserve des donnees, des variables et 
des resultats intermediaires de traitement utilises par les programmes stockes 
en memoire 204B. dans des segments de memoire portant, dans la suite de la 
description, les memes noms que les donnees dont lis conservent les valeurs. 

En cours de fonctionnement, la memoire flash 204B contient le 
BIOS et les logiciels de controle (qui operent avec le systems d'exploitation 
temps-reel CHORUS (marque deposee)) qui sont decrits en figure 3 a 7. 

La memoire vive 204 comporte notamment : 

un segment de memoire " userjdata " dans lequel sont 
conservees les informations utilisateur a transmettre, dont, en particulier, le 
service requis (comportant la bande passante necessaire), 

- un segment de memoire " addjdata " dans lequel sont conservees 
des informations additionnelles a transmettre, informations qui definissent, 
notamment, dans son integralite. le chemin a suivre par les donnees utilisateur 
sur le reseau de communication (figure 9). et 

- un segment de memoire " Tables " dans lequel sont conservees 
une table de charge de chemins et une table de charge de liens comportant des 
informations decrivant tous les chemins dont le noeud considers est la source 
et tous les liens faisant partie de ces chemins (figures 10 et 1 1). 

La zone d'extension de memoire 236 est adaptee k conserver : 

- le programme de fonctionnement de Tunite centrale de traitement 
206, dans un segment de memoire " programi et 

- un identificateur representatif du moyen de communication 112, 
identificateur qui est unique sur le reseau de communication. 

A rinitialisation du moyen de communication, le programme stock6 
dans la m6moire d'extension 236 est au moins partiellement copi6 et organise 
dans la zone memoire d'execution 204B. 

La zone d'extension de m6moire 236 constitue un moyen de 
stockage d'informations lisibles par un ordinateur ou un microprocesseur, 
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conservant des instmctions d'un programme informatique caracterise en ce qu'il 
permet la mise en oeuvre du precede de Tinvention. Selon une variante, la zone 
d'extension de memoire 236 est amovible. partiellement ou totalement. et 
comporte. par exemple, une bande magnetique, une memoire flash, une 
disquette ou un compact disque a memoire figee ("CD-ROM" en anglais). 

Dans le mode de realisation decrit et represente. le moyen de 
traitement utilise le moyen de communication conforme a I'invention. Le moyen 
de traitement demande retablissement d'une connexion au moyen de 
communication en lui faisant part du service requis ("application requirement" 
en anglais). Ces parametres dits de "service requis" sent, d'une part, transmis 
dans certains messages de signalisation et, d'autre part, utilises pour calculer 
les parametres de transmission ("trafic parameters" en anglais). Le sen/ice 
requis est I'etalon utilise pour la mise S jour des tables de charges dans les 
differents noeuds du reseau car il ne depend pas de I'fetat respectif des tables 
de charges. 

Les organigrammes objets des figures 4 a 7 n'illustrent que 
partiellement le fonctionnement des dispositifs de communication. 

L'unite centrale de traitement 206 est adapt6e a mettre en oeuvre 
les organigrammes decrits en figures 4^7. 

En figure 3, on observe, symbolises par des fleches descendantes 
placees dans une colonne centrale, des messages transmis sur le r6seau, entre 
un noeud source, a gauche, et un noeud destinataire, a droite. Les fleches 
orient6es de la gauche vers la droite correspondent a des messages transmis 
depuis le noeud source des donnees utilisateur a destination du noeud 
destinataire de ces donnees et les fleches orientees de la droite vers la gauche 
correspondent ^ des messages transmis depuis le noeud destinataire des 
donn6es utilisateur vers le noeud source de ces donnees. 

Dans la colonne de gauche, sont repr6sentes les messages 
6chang6s entre le moyen de traitement du noeud source (d gauche) et le 
moyen de communication du noeud source (a droite de la colonne de gauche). 
Dans la colonne de droite, sont repr6sent6s les messages echang6s entre le 
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moyen de traitement du noeud destinataire (a droite) et le moyen de 
communication du noeud destinataire (a gauclie de la colonne de droite). 

Les six Heches 251 a 256 de la colonne centrale correspondent a 
un mode de communication connects conforme a la presente invention, les 
5 fleches 257 et 258 correspondent a une transmission en mode non connecte 
avec synchronisation des deux moyens de traitement et la fleche 259 
correspond a une communication en mode non connecte sans synchronisation 
des deux moyens de traitement. 

Dans la colonne centrale. les fleches 254. 257. 258 et 259 
10 correspondent ^ des transferts de donnees sur le reseau. les autres fleches 
correspondant a des messages organ isant ces transferts. 

En mode connecte, c'est-a-dire dans le cas du trafic connecte, le 
moyen de traitement du noeud source informe le moyen de communication du 
noeud source de I'ouverture d'une connexion en lui envoyant un message de 
1 5 requete de connexion {"connect_req'') 

En consequence, le moyen de communication du noeud source 
lance la phase d'initialisation ("sef-up" en anglais). Cette phase comporte 
notamment remission d'un message d'initialisation 251 (message "sef-t/p") par 
le moyen de communication du noeud source et a destination du moyen de 
20 communication du noeud destinataire (par Tintermediaire, le cas echeant, du 
moyen de communication de chaque noeud intermediaire). 

A reception du message de "set-up", le moyen de communication 
du noeud destinataire informe le moyen de traitement du noeud destinataire 
qu'il a regu une demande d'ouverture de connexion, par I'intermediaire d'un 
25 message de demande d'ouverture de connexion "connectjnd". 

Si la demande est acceptee, le moyen de communication du 
noeud destinataire est informe par le moyen de traitement du noeud 
destinataire, par I'intermediaire d'un message "connect_ans'* (identifi§ en figure 
6 par le nom "callRequest_ack!' pour acceptation de requete d'appel ou de 
30 "callRequest_nacK\ pour rejet de requete d'appel, selon le resultat de la demande 
d'ouverture de connexion, operations 377 et 378 respectivement. Dans le premier 
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cas, un message de connexion 252 Coonnecf) est emis par le moyen de 
communication du noeud destinataire vers le moyen de communication du 
noeud source. 

Le moyen de traitement du noeud source est alors informe du bon 
deroulement de I'ouverture de la connexion par un message de confirmation de 
connexion "connect_cfr'\ de la part du moyen de communication du noeud 
source. Le moyen de communication de chaque noeud du reseau est alors 
inform6 de Tetablissement d'une nouvelle connexion par I'interm6diaire d'un 
message 253 de mise a jour de table de charge ""LinkTabLoad" diffuse par le 
moyen de communication du noeud source. Ce message est aussi utilise pour 
confirmer aupres des noeuds intermediaires et du noeud destinataire le bon 
deroulement de la phase d'etablissement de la connexion. 

Le transfert de donn6es composant le trafic connecte associe a la 
connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A 
cet effet. le moyen de traitement du noeud source et le moyen de 
communication du noeud source 6changent des messages de demande 
d'emission d'un message de donnees ''sendlsoData_req" et de confirmation 
d'emission du message de donnees "sencllsoData_cfr", 

Le transfert des messages de donnees 254 est alors effectue 
apres segmentation du flot de donnees en paquets de taille predefmie. Le 
moyen de communication du noeud destinataire regoit les paquets de donnees 
qu'il confie au moyen de traitement du noeud destinataire, par Tintermediaire du 
message de reception d'un message de donnees ''sendlsoDataJncT), apr^s 
avoir restructure le flot de donn6es. 

Lorsque les donnees ^ transmettre ont et6 transmises. le moyen 
de traitement du noeud source peut decider de la fermeture d'une connexion en 
transmettant un message de demande de fermeture de connexion 
"re/ease_req" au moyen de communication du noeud source. 

Le moyen de communication du noeud source 6met alors : 
- un message de confirmation de relachement ''release__cff ^ 
destination du moyen de traitement du noeud source, 
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- un message de relachement '"release" 255 a destination des 
6ventuels noeuds intermediaires et du noeud destinataire, at 

- un message 256 de mise a jour de table de charge "LinkTabFree" 
a tous les noeuds du reseau. 

Le message 256 est utilise pour confirmer aupres des noeuds 
intermediaires, des noeuds voisins et du noeud destinataire le bon deroulement 
de la phase de liberation de la connexion. Au niveau du noeud destinataire, le 
moyen de communication informe le moyen de traitement de la fermeture de la 
connexion par Tintermediaire d'un message de notification de fermeture de 
connexion "release_incr\ 

Le transfert de donnees pour le trafic elastique, en mode non 
connecte avec synchronisation des moyens de traitement, se fait sans 
ouverture prealable d'un connexion, par la transmission du message d'emission 
de message "senclSyncData_req'' par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 257 des donnees apres segmentation du 
flot de donnees en paquets de taille predefinie. Au niveau du noeud 
destinataire, la reception des donnees est effectuee par le moyen de 
communication, qui informe le moyen de traitement, et transmet le flot de 
donnees restructure, par Tusage du message de reception de message 
"sendSyncDataJn(f \ En r6ponse. le moyen de traitement du noeud destinataire 
emet, a destination du moyen de communication du noeud destinataire, un 
message de bonne reception '*sendSyncData_ans'\ qui contient la reponse du 
moyen de traitement du noeud destinataire et provoque le transfert d'un 
message 258 entre le moyen de communication du noeud destinataire et le 
moyen de communication du noeud source. A reception de ce message 258, le 
moyen de communication du noeud source emet d destination du moyen de 
traitement du noeud source un message de confirmation de transmission 
"sendSyncData_cfi*\ 

Le transfert de donnees pour le trafic elastique, en mode non 
connects sans synchronisation des moyens de traitement, se fait sans 
ouverture prealable d'un connexion, par la transmission du message d'6mission 
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de message "sendAsyncData_req" par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 259 des donnees apres segmentation du 
flot de donnees en paquets de taille predefinie et emet a destination du moyen 
de traitement du noeud source un message de confirmation "de transmission 
"sendAsyncData^cff". Au niveau du noeud destinataire. la reception des 
donn6es est effectuee par le moyen de communication, qui informe le moyen 
de traitement et transmet le flot de donnees restnjcture, par I'usage du 
message de reception de message "sendAsyncDataJnd". 

Les figures 4 a 7 illustrent les procedures de gestion des 
connexions selon I'invention. 

En ce qui conceme le moyen de communication du noeud source, 
apres avoir ete dans un etat d'initialisation 300 (figure 4), un message entrant 
"connect_req" est regu au cours d'une operation 301, de la part du moyen de 
traitement du noeud source. Ce message comporte le service requis, dont la 
bande passante, et le mode de transmission. Le moyen de communication du 
noeud source effectue alors la selection d'un chemin alloue a la connexion, le 
calcul des parametres de transmission en fonction du service requis puis la 
mise a jour de la table de charge si un chemin est disponible (figure 13), au 
cours d'une operation 302. 

Ensuite, au cours d'un test 304, le moyen de communication du 
noeud source determine si la bande passante necessaire S la connexion 
envisagee est disponible sur le chemin selectionne, ou non. Cette procedure de 
test 304 est connue sous le nom de " Controle d'Ad mission de Connexion " ou 
encore "CAC". Lorsque le resultat du test 304 est negatif. au cours d'une 
operation 303, le moyen de communication emet un message de refus 
d'ouverture (message ''connectjcff' n6gatif) de communication a destination du 
moyen de traitement du noeud source. Ce message de refus "connect_cfr" 
n6gatif a pour effet d'avertir Tapplication logicielle qui avait requis la 
transmission de Timpossibilite d'effectuer cette transmission en mode con necte. 
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Ensuite, les ressources associees a la gestion de la connexion 

sont liberees. 

Lorsque le resultat du test 304 est positif, au cours d'une operation 
305, le moyen de connmunication 6met le message 251 "seZ-op" (figure 3) a 
destination du moyen de communication du noeud destinataire, par 
rintermediaire de chacun des dispositifs de communication des eventuels 
noeuds intermediaires. Ce message 251 decrit la connexion a etablir (voir figure 
9). 

Ensuite, au cours d'une operation 306, un compteur d'horloge (en 
anglais "timer) "cncAckWair est initialise a une valeur qui correspond a un 
delai maximum accorde a I'etablissement de la connexion demandee. Le 
moyen de communication se met alors dans un etat d'attente de la reponse du 
reseau quant a I'etablissement de la connexion, etat 307. 

Dans cet etat 307, trois evenements differents peuvent se 
produire, au cours d'operations 308, 310 ou 311. 

Lorsque, dans I'etat 307, le message entrant est un message 
"cnCiAc/cW/a/r. provenant du passage a zero de la valeur du compteur de 
signaux d'horloge "cnc/!\c/cWa/r initialise au cours de Toperation 306, operation 
308, ou lorsque le message entrant est un message "re/ease_bac/c", provenant 
du noeud destinataire ou de I'un des eventuels noeuds intermediaires, 
operation 310, I'operation 323 est effectuee, au cours de laquelle le moyen de 
traitement du noeud source est informe du rejet de la demande de connexion. A 
cet effet, le moyen de communication du noeud source emet un message 
"openCall_nacl^\ correspondant a un message '*connect_cfr*' negatif. notifiant le 
rejet de la connexion, a destination du moyen de traitement du noeud source. 

A la suite de I'operation 323, au cours d'une operation 324, le 
moyen de communication du noeud source precede a la mise a jour des tables 
de charge associees a la connexion qui a ete rejetee. Puis, au cours d'une 
operation 325, les ressources associees a la gestion de la connexion sont 
liberees. 
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Enfin. lorsque, dans I'etat 307, le message entrant est un 
message de connexion 252 "connecf\ provenant du noeud destinataire. 
operation 311, ie moyen de communication du noeud source effectue remission 
d'un message d'acquittement d'ouverture de connexion '*openCall_acf^\ 
5 correspondant a un message '*connect_cfr" positif, a destination du moyen de 
traitement du noeud source, operation 312, puis, au cours d'une operation 313, 
diffuse un message 253 "'LinkTabLoacT' comportant notamment la description 
du service requis, la bande passante utilisee ainsi que la description du chemin 
correspondent a la connexion, en termes de liens. Ce message est diffuse a 
10 destination de tous les noeuds du reseau, ce qui a pour effet que chaque noeud 
du reseau met a jour ses tables de charge. La diffusion de ce message est 
effectuee en suivant un arbre de recouvrement du reseau. determine selon des 
techniques connues (voir figure 8). 

Le moyen de communication du noeud source se met alors dans 
15 I'etat 314 au cours duquel il attend une evolution de la connexion et transmet 
toutes les donnees destinees a etre transmises en mode connecte, sur la 
connexion mise en place. 

Deux messages peuvent alors entrer dans le moyen de 
communication, au cours d'op6rations 315 et 318. 

20 Lorsque, dans I'etat 314, le message entrant est un message de 

relachement provenant d'un autre noeud du reseau "release_bacf^\ operation 
315, le moyen de communication du noeud source emet un message de 
terminaison de communication "callTerminate'\ "releaseJncT" figure 3, a 
destination du moyen de traitement du noeud source, operation 316. ce qui a 

25 pour effet d'informer le moyen de traitement de la fermeture de la connexion. 

Puis, le moyen de communication emet un message d'alarme 
"alarm_dcnBack'\ operation 317, ^ destination du moyen de traitement du 
noeud source, ce qui a pour effet de declencher le traitement d'une alarme par 
ce moyen de traitement puisque la connexion a 6te interrompue de maniere 
30 anormale. Puis, le moyen de communication diffuse S destination de tous les 
autres noeuds du r6seau, un message de mise S jour de tables de charges 
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'"LinkTabFree", comportant notamment une description du service requis et du 
chemin correspondent a la connexion, en termes de liens, operation 320. 

Le moyen de communication effectue alors une operation 321, 
identique a Toperation 324, puis une operation 322 au cours de laquelle les 
5 ressources associees a la gestion de la connexion sont detruites. 

Lorsque le message regu, dans Tetat 314. est un message de 
demande de fin de connexion (message ''release_req" provenant du moyen de 
traitement du noeud source et message '*release_cfr'\ en reponse), operation 
318. le moyen de communication emet un message de relachement 255 
10 "release", operation 319, puis effectue les operations 320. 321 et 322. 

En ce qui concerne chaque noeud intermediaire (figure 5), apres 
avoir ete dans un etat d'initialisation 300. un message entrant 251 "set-up" est 
regu au cours d'une operation 331. de la part du noeud source (voir operation 
305). Le service requis pour la connexion consideree est alors extrait de ce 
15 message 251 "set-up". Le moyen de communication du noeud intermediaire 
effectue alors un calcul des parametres de transmission, a partir du service 
requis. puis, si la charge est acceptable, une mise a jour de ses tables de 
charge, au cours d'une operation 332. detaillee figure 14. 

Ens»J'te. 3U cours d'un test 335. le moyen de communication du 
20 noeud intermediaire determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non (voir test 304). 

Lorsque le resultat du test 335 est negatif. au cours d'une 
operation 333, le moyen de communication du noeud intermediaire emet un 
message de relachement de connexion " release JbacK" a destination du noeud 
25 source (voir operation 310). Puis le moyen de communication du noeud 
intermediaire lib^re les ressources associ6es ^ la gestion de la connexion 
consideree, operation 334. 

Lorsque le r6sultat du test 335 est positif, au cours d'une op6ration 
336, le moyen de communication 6met un message d'initialisation "set-up" 251 
30 a destination du moyen de communication du noeud destinataire et de chacun 
des moyens de communication des eventuels noeuds intermediaires. Ce 
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message est emis apres mise a jour du champ identifiant la position du noeud 
dans le chemin, a partir de la description du chemin en termes de liens (voir 
figure 9). 

Ensuite. au cours d'une operation 337, le compteur d'horloge 
"cncAckWaiT est initialise a une valeur qui correspond a la duree maximale 
accordee a Tetabiissement de la connexion. Le moyen de communication se 
met alors dans Tetat 338 d'attente de la reponse du reseau quant a 
Tetablissement de la connexion. 

Dans cet etat 338, cinq evenements differents peuvent se 
produire, au cours d'operations 339, 341, 345, 346 et 347. 

Lorsque le message entrant est un message "cncAckWaiT, 
provenant du passage a zero de la valeur du compteur de signaux d'horloge 
''cncAckWaif initialise au cours de I'operation 337. operation 339, le moyen de 
communication 6met un message de relachement "release", operation 340, a 
destination du noeud destinataire et des eventuels noeuds intermediaires qui le 
s6parent du noeud destinataire, et emet un message de relachement 
" release Jback\ a destination du noeud source et des eventuels noeuds 
intermediaires qui le separent du noeud source, operation 342. Ensuite. au 
cours d'une operation 343, le moyen de communication du noeud intermediaire 
considere procede a la mise a jour des tables de charge associees a la 
connexion qui a ete rejetee. Puis, au cours d'une operation 344, les ressources 
associees a la gestion de la connexion sont lib§rees. 

Lorsque le message entrant est un message Ve/ease" 255, 
provenant du noeud source ou d'un noeud intermediaire entre le noeud source 
et le noeud intermediaire consid6re, operation 341. le moyen de communication 
effectue les operations 342 a 344. 

Lorsque. dans r§tat 338. le message entrant est un message 256 
"LinkTabFree", operation 347, ce message est memorise et le moyen de 
communication reste dans Fetat 338. 

Lorsque, dans retat 338, le message entrant est un message de 
demande de fin de connexion 6mis par un moyen de controle de noeud, dont la 
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fonction est de prendre en compte les differents problemes du reseau, 
operation 346. ce message est memorise et le moyen de communication reste 
dans r^tat 338. 

Enfin, lorsque le message entrant est un message 253 
5 ''UnkTabLoad\ comportant notamment la description du sen/ice requis. ainsi 
que la description du chemin en termes de liens, en provenance du noeud 
source (voir operation 313)» operation 345, le moyen de communication se met 
dans un etat 348 au cours duquel il attend une evolution de la connexion et 
transmet toutes les donnees destinees a etre transmises en mode connecte, 
10 sur la connexion mise en place. 

On observe ici que le message 253 ''LinkTabLoad' a, vis a vis 
d'un noeud intermediaire (et du noeud destinataire), pour fonction de confirmer 
retablissement de la connexion, au cours de Toperation 345. 

Dans Tetat 348, trois evenements peuvent se produire, au cours 
1 5 d'operations 349. 350 et 351 . 

Lorsque. dans I'etat 348. le message entrant est un message 256 
''LinkTabFree", operation 351, ce message est memorise et le moyen de 
communication reste dans I'etat 348. 

Lorsque. dans I'etat 348, le message entrant est un message 255 
20 "re/ease", I'operation 353 decrite plus loin est effectuee. 

Enfin, lorsque. dans I'etat 348, le message entrant est un 
message de demande de fin de connexion, emis par un moyen de controle de 
noeud. operation 350, le moyen de communication emet un message de 
relachement "re/ease_bac/c" a destination du noeud source, operation 352. 

25 A la suite de Tune des operations 349 ou 352, le moyen de 

communication effectue, au cours d'une operation 353, remission d'un message 
de relachement "re/ease" ^ destination du noeud destinataire et de chaque 
eventuel noeud intermediaire qui separe le noeud intermediaire considere et le 
noeud destinataire. 
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Le moyen de communication effectue alors une operation 354 
identique a Toperation 324, puis une operation 355 au cours de laquelle le 
compteur d'horloge ''cncAckWaif est initialise a une valeur qui correspond a la 
duree maximale accordee a la liberation de la connexion. Le moyen de 
5 communication se met alors dans Tetat 356 d'attente de la reponse du reseau 
quant au relachement de la connexion. 

Dans Tetat 356, deux messages peuvent survenir, au cours 
d'operations 357 et 358. 

Lorsque le message entrant est un message 256 '*LinkTabFree'\ 
10 operation 357. les ressources associees a la gestion de la connexion sont 
liberees, operation 360. 

Lorsque, dans Tetat 356, le message entrant est un message 
"cncAckWaif\ provenant du passage S z6ro de la valeur du compteur de 
signaux d'horloge "cnc>4c/cl1/a/f" initialise au cours de Toperation 355, operation 
15 358. le moyen de communication emet un message d'alarme "alarm_dcnTO'\ 
operation 359, a destination d'un moyen de controle de noeud, ce qui a pour 
effet de declencher le traitement d'une alarme par ce moyen de traitement 
puisque la connexion n'a pas et6 relachee de mani^re normale. 

A la suite de Tune des operations 357 ou 359. les ressources 
20 associees a la gestion de la connexion sont liberees, operation 360. 

En ce qui concerne le noeud destinataire, (figure 6), apres avoir 
ete dans un etat d'initialisation 370, un message entrant "sefL/p_encf' est regu 
au cours d'une operation 371, de la part du noeud source ou d'un noeud 
intermediaire. Le moyen de communication du noeud destinataire effectue alors 
25 {'extraction du service requis, op6ration 371, puis le calcul des parametres de 
transmission ^ partir du service requis, et, si la charge est acceptable, la mise ^ 
jour de la table de charge, au cours d'une op6ration 372 similaire ^ reparation 
332, decrite figure 14. 

Ensuite, au cours d'un test 373, le moyen de communication du 
30 noeud destinataire determine si la bande passante n6cessaire ^ la connexion 
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envisag6e est disponible sur le chemin selectionne, ou non (voir tests 304 et 
335). 

Lorsque le resultat du test 373 est negatif. au cours d'une 
operation 333, le moyen de communication du noeud destinataire emet, a 
destination du noeud source et de tous les eventuels noeuds intermediaires. un 
message de relachement "release^back", au cours d'une operation 380. 
Ensuite, les ressources associees a la gestion de la connexion sont liberees, 
operation 382. 

Lorsque le resultat du test 373 est positif, le moyen de 
communication du noeud destinataire emet, a destination du moyen de 
traitement du noeud destinataire un message de demande de connexion 
"connectJn<f \ au cours d'une operation 374, 

Puis, le moyen de communication se met dans un etat 375 
d'attente de la reponse du moyen de traitement du noeud destinataire. 

Dans I'etat 375. trois evenements peuvent survenir, au cours 
d'operations 376, 377 et 378. Lorsque le message entrant est un message de 
relachement "release", provenant du noeud source ou de Tun des noeuds 
intermediaires, il est memorise au cours de Toperation 376. 

Lorsque, dans Tetat 375. le message entrant est une reponse 
defavorable "callReq_nack", correspondant a un message "connect_ans" 
negatif (figure 3), provenant du moyen de traitement du noeud destinataire, 
operation 378, au cours d'une operation 379. le moyen de communication du 
noeud destinataire precede a la mise a jour des tables de charge associees a la 
connexion qui a ete rejetee. Puis les operations 380 et 382 sont effectu6es. 

Enfin, lorsque, dans Tetat 375, le message entrant est un 
message favorable "ca//Req_ac/c", correspondant S un message "connect_ans" 
positif (figure 3), en provenance du moyen de traitement du noeud destinataire, 
op6ration 377, le moyen de communication 6met un message 252 "connecf, 
directement vers le noeud source, par mise en oeuvre du moyen de routage, au 
cours d'une operation 381. Ensuite. au cours d'une operation 383, le compteur 
d'horloge "cncAckWaif' est initialise a une valeur qui correspond a un d6lai 
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maximum accorde a I'etablissement de la connexion demandee. Le moyen de 
communication se met alors dans Tetat d'attente de la reponse du reseau quant 
a Tetabiissement de la connexion, etat 384. 

Dans cet etat 384. cinq evenements peuvent survenir au cours 
5 d'operations 385, 386. 387, 389 et 390. 

Lorsque le message entrant est un message de relachement 
"re/ease", provenant du noeud source ou de Tun des noeuds intermediaires, il 
est memorise au cours de I'operation 385. 

Lorsque. dans I'etat 384, le message entrant est un message de 
10 mise a jour de table de charge 256 ''LinkTabFree", provenant du noeud source, 
il est memorise au cours de I'operation 389. 

Lorsque, dans I'etat 384, le message entrant est un message de 
demande de fin de connexion provenant du moyen de traitement ou d'un 
moyen de controle de noeud, il est memorise au cours de I'operation 386. 

15 Lorsque, dans I'etat 384. le message entrant est un message 

"cncAckWaif\ provenant du passage a zero de la valeur du compteur de 
signaux d'horloge ''cncAckWatT initialise au cours de I'operation 383. operation 
390, le moyen de communication emet un message de relachement de 
connexion "release__bacf^\ operation 391. a destination des noeuds 

20 intemnediaires et du noeud source. 

Ensuite, au cours d'une operation 392, le moyen de 
communication du noeud destinataire precede a la mise a jour des tables de 
charge associees ^ la connexion qui a ete rejetee. Puis, au cours d'une 
operation 393, les ressources associees ^ la gestion de la connexion sont 
25 liberies. 

Enfin, lorsque, dans r6tat 384, le message entrant est un 
message 253 "LinkTabLoacr\ message comportant notamment la description 
du service requis ainsi que la description du chemin en terme de liens 
(message ayant pour fonction de confirmer I'etablissement de la connexion), 
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operation 387, le moyen de communication du noeud destinataire se met dans 
un etat 388 d'attente d'evolution de la connexion. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud intermediaire, pour fonction de confirmer I'etablissement de la 
5 connexion. 

Dans I'etat 388, trois evenements peuvent survenir, au cours 
d'operations 394, 396 et 397. 

Lorsque, dans Tetat 388. le message entrant est un message de 
mise a jour de table de charge 256 "LinkTabFree'\ provenant du noeud source, 
10 11 est memorise au cours de Toperation 396. 

Lorsque. dans Tetat 388. le message entrant est un message de 
relachement 255 "re/ease", operation 397, le moyen de communication effectue 
la notification ''callTerminate", correspondent a un message "releasejncf' 
(figure 3), de la rupture de la connexion au moyen de traitement du noeud 
15 destinataire, operation 398. Ensuite. Toperation 399 decrite plus loin est 
effectuee. 

Enfin, lorsque, dans Tetat 388, le message entrant est un 
message de demande de fin de connexion emis par un moyen de controle de 
noeud. operation 394. le moyen de communication emet un message de 
20 relachement ''release_bacl^' a destination du noeud source et des noeuds 
intermediaires, operation 395. 

A la suite de Tune des operations 395 ou 398. le moyen de 
communication effectue une operation 399 identique a I'operation 324. puis une 
operation 400 au cours de laquelle le compteur d'horloge "cnc>Ac/cWa/f' est 
25 initialise a une valeur qui correspond S la dur6e maximale accord6e ^ la 
lib6ration de la connexion. Le moyen de communication se met alors dans r§tat 
401 d'attente de la r6ponse du reseau quant au relachement de la connexion 
de la meme fagon que pour les noeuds intermediaires. 

Dans retat 401. deux messages peuvent survenir, au cours 
30 d'operations 402 et 403. 




Lorsque le message entrant est un message 256 "LinkTabFree'\ 
operation 402. les ressources associ§es a la gestion de la connexion sont 
liberees, operation 405. 

Lorsque, dans Tetat 401, le message entrant est un message 
''cncAckWaif\ provenant du passage a zero de la valeur du compteur de 
signaux d'horloge "cncAckWaif initialise au cours de Toperation 400, operation 
403. le moyen de communication emet un message d'alarme "alarm_dcnTO"\ 
operation 404. a destination du moyen de controle de noeud, ce qui a pour effet 
de declencher le traitement d'une alarme par ce moyen de traitement puisque la 
connexion n'a pas §te relachee de maniere normale. 

A la suite de Tune des operations 402 ou 404. les ressources 
associees a la gestion de la connexion sont liberees. operation 405. 

En ce qui concerne chaque noeud voisin (figure 7). apres avoir ete 
dans un etat d'initialisation 411, le moyen de communication du noeud voisin 
revolt un message 253 ""UnkTabLoacf', comprenant notamment la description 
du service requis ainsi que la description du chemin en termes de liens, 
operation 412. Ensuite, au cours d'une operation 413, le moyen de 
communication du noeud voisin effectue le calcul des parametres de 
transmission ^ partir du service requis. puis, independamment de la charge, la 
mise a jour de la table de charge. 

Ensuite. dans Tetat 414. le moyen de communication du noeud 
voisin attend r6volution de la connexion. Ensuite, au cours d'une operation 415, 
il regoit un message 256 "LinkTabFree" concemant la connexion, message 
comprenant notamment la description du service requis ainsi que la description 
du chemin en termes de liens. 

Ensuite. au cours d'une operation 416. le moyen de 
communication du noeud voisin procede ^ la mise a jour des tables de charge 
associees a la connexion qui a 6t6 Iib6r6e. Puis, au cours d'une operation 417, 
les ressources associees a la gestion de la connexion sont liberees. 

On observe ici que le message 253 "LinkTabLoacT" a, vis d vis 
d'un noeud voisin, pour fonction d'informer sur r6tablissement de la connexion. 
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Ainsi la procedure (figure 7) correspond plutot a une notification 
qu'^ un controle d'admission. 

En figure 8 sont representes, dans un reseau a commutation de 
paquets 800 : 

- un noeud source 801 , 

- un noeud destinataire 802, 

- deux noeuds intermediaires 803 et 804, 

- cinq noeuds voisins 805 a 809, et 

- les liens entre ces noeuds. 

Le long de ces liens sont representes des messages transitant 
successivement sur le reseau ainsi constitue. sous forme de fleches. 

On observe que le message 251 "set-up" circule : 

- du noeud source 801 au noeud intermediaire 803, puis 

- du noeud intermediaire 803 au noeud intermediaire 804, puis 

- du noeud intermediaire 804 au noeud destinataire 802. 

En revanche, le message 252 "connecr retoume directement du 
noeud destinataire 802 au noeud source 801. sans intervention des noeuds 
intermediaires 803 ou 804. Ce message 252 peut, en fait, passer par n'importe 
quel chemin entre le noeud destinataire et le noeud source, par exemple par un 
chemin passant par le noeud voisin 808. 

Enfin, les messages de mise a jour de table de charge 253 
"LinkTabLoad" et 256 "LinkTabFree" sont diffuses a tous les noeuds du reseau, 
en suivant un arbre de recouvrement. 

Preferentiellement, toutes les extr6mites, ou "feuilles" de Tarbre de 
recouvrement se trouvent sur le chemin de la connexion. Ainsi. lorsqu'il y a une 
panne dans le reseau, les noeuds du chemin, noeuds intermediaires ou noeud 
destinataire. qui, comme on I'a vu dans les organigrammes des figures 5 et 6, 
attendent le message ''UnkTabLoad' 253, respectivement dans les 6tats 345 et 
387, peuvent detecter la panne lorsque Tun des noeuds voisins ne transmet pas 
ce message. 
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En figure 9, on observe, sur quatre lignes successives, les 
structures des messages 251 '"set-up", 255 "released de mise a jour de table de 
charge, 253 ''LinkTabLoad' ou 256 "LinkTabFree'' et 252 "connecf\ 

Le message 25i "set-up" comporte successivement les champs : 

- 901. d'identification du type de message {"set-up", 
"LinkTabLoad", "LinkTabFree", "Connecr ou "Release", voir figure 3), 

- 902. d'identification de connexion, 

- 903. de description de trafic. representatif du service requis, 

- 904. de donnees propres au moyen de communication 
permettant notamment d'identifier les moyens de traitement des noeuds source 
et destinataire. 

- 905, de nombre de liens qui utilisent le cliemin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 

associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

Le message 255 "release" comporte successivement. les 

champs : 

- 901, d'identification du type de message ("sef-up", 
"UnkTabLoad\ ''LinkTabFree", "Connecf ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 909, de cause de la demande de relachement, 

- 905, de nombre de liens qui utilisent le chemin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le 
chemin associe ^ la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhait6e. et 

- 908, de donn6es de protocole. 
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Un message de mise a jour de table de charge 253 ou 256 
comporte successivement les champs : 

- 901, d'identification du type de message ("set-up", 
"LinkTabLoacf\ "LinkTabFree", ''Connecr ou "Release", voir figure 3), 

5 - 902, d'identification de connexion, 

- 903, de description de trafic, representatif du service requis. 

- 910. d'information relative a Tarbre de recouvrement mis en 

oeuvre, 

- 905. de nombre de liens qui utilisent le chemin associe a la 

10 connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondent a la connexion souhaitee, et 

15 - 908, de donnees de protocole. 

Le message 252 "connecr comporte successivement les 

champs : 

- 901. d'identification du type de message {"set-up", 
"UnkTabLoacf\ "LinkTabFree", "Connecf ou "Release", voir figure 3), 

20 - 902, d'identification de connexion, 

- 911. de donnees de protocole. pouvant etre utilisees par le 
moyen de traitement du noeud source. 

- 908, de donnees de protocole. 

En figure 10, on observe des descripteurs de liens 1001 a 1007 
25 disposes cote a cote et des descripteurs de chemins 101 1 a 1015 disposes sur 
des lignes successives. 

Chaque descripteur de chemin est une structure de donn6es pour 
la descripfion d'un chemin qui comporte, en particulier la reference des liens 
impliques dans la description de ce chemin et la reference de chaque 
30 connexion associee a ce chemin. Chaque descripteur de chemin sortant (1011, 
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1012 ou 1013) concerne un chemin cree par le moyen de routage du moyen de 
communication. 

Les chemins qui ne partent pas du noeud considere sont dits 
"temporaires" et permettent de connaTtre les charges des liens des chemins 
sortants. Les chemins temporaires sont crees par le moyen de controle de 
charge qui gere tous les chemins (operations 1307, 1407 et 1504. figures 13 a 
15). 

Dans le mode de realisation decrit et represents, les chemins 
1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 
1014 et 1015 sont des chemins temporaires (en traits fins), Les chemins 1011, 
1012 et 1013 decrivent la table de routage et sont utilises par le noeud 
considere pour etablir des chemins vers n'importe quel noeud destinataire. 

Chaque descripteur de lien 1001 a 1007 comporte, en particulier, 
la reference de chaque chemin qui traverse le lien consider^, identifie par un 
rectangle, a I'intersection d'une ligne verticale partant du descripteur de lien 
considere et d'une ligne horizontale partant du descripteur de chemin 
considere. 

Les liens 1001 a 1004 font partie d'au moins Tun des chemins 
sortants, et sont representes en traits gras. Chaque intersection de deux lignes 
marquee par un point represente une reference en memoire : 

- les lignes externes (en haut et/ou a gauche des rectangles) 
reperent les references conser\/ees avec chaque lien : ces references 
concernent chaque chemin qui traverse ledit lien, et 

- les lignes internes (en bas et/ou a droite des rectangles) reperent 
les references conservees avec chaque chemin : ces references concernent 
chaque lien traverse par ledit chemin. 

La mise ^ jour de la table de charge effectuee par le moyen de 
controle de charge, comporte les 6tapes suivantes : 

- pour Tetablissement d'une connexion : 

• mise ci jour de la charge de tous les liens references par 
le chemin (ajout de charge), et 
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• pour chaque lien, mise a jour de la charge de chaque 
chemin reference pource lien ; 

- pour le retrait d'une connexion : 

• mise a jour de la charge de tous les liens references par 
le chemin (deduction de charge), at 

• pour chaque lien, mise a jour de la charge de chaque 
chemin reference pour ce lien ; 

- pour Tajout d'un chemin : 

• soit par le moyen de routage, lors de Tetablissement de 
la table de routage du noeud considere (il s'agit alors 
d'un chemin sortant), ou lors de la mise a jour de la table 
de routage. 

• soit par le moyen de controle de charge, lorsque le 
chemin associe a une nouvelle connexion lors de I'ajout 
de charge n'est pas deja specifie (il s'agit alors de 
chemin temporaire) ; 

- pour la suppression d'un chemin : 

• par retrait d'un chemin temporaire lorsqu'il n'est plus 
traverse par aucune connexion, apres retrait d'une 
connexion, soit lorsque la liste de connexions referencee 
par ce chemin est vide, 

- pour la transformation d'un chemin sortant en chemin temporaire 
lorsqu'il ne fait plus partie de la table de routage (a la suite d'une operation de 
mise a jour de la table de routage) ; et 

- pour la suppression d'un lien : 

• par retrait d'un lien lorsqu'il n'est plus traverse par aucun 
chemin, ou lorsque la liste des chemins references par 
ledit lien est vide. 

Dans la table de charge, ^ chaque lien est associ6e une 
information de charge et a chaque chemin est associ6e une information 
representative du lien le moins disponible. Ainsi. la bande passante disponible 
du lien le moins disponible est aussi la bande passante disponible du chemin. 
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On observe que c'est en utilisant cette infornnation de disponibilite 
de bande passante de chemin. que le moyen de comnnunication effectue le 
choix du chemin en choisissant le chemin le plus disponible. Pour chaque 
information a transmettre en mode non connecte, la disponibilite de chaque 
5 chemin du reseau est ainsi estimee, en fonction du trafic en mcJde connecte. 

La charge d'un chemin est definie a partir de son lien le moins 
disponible. II est caracterise par la bande passante totale qu'il autorise et la part 
maximale de la bande passante associee au trafic en mode connecte. Etant 
donnee la charge effective du trafic en mode connecte, chaque moyen de 
10 communication definit la part associee au trafic en mode non connecte. comme 
egale a la bande passante totale a laquelle on a soustrait la part associee au 
mode connecte, 

Le moyen de communication alloue a Tensemble des 
transmissions en mode non connecte qu'il a a effectuer. tout ou partie de la 
15 bande passante (preferentiellement une partie, pour eviter des problemes de 
congestion du reseau). Cette part est equitablement repartie entre toutes les 
transmissions en mode non connecte et se trouve done dynamiquement mise a 
jour au debut et a la fin de chaque transmission en mode connecte (lorsque la 
charge du trafic en mode connecte varie). 

20 L'attribution d'une part est effectuee en definissant un plage de 

valeurs du nombre de paquets d emettre entre deux valours extremes 
(spec_CPmin 1114 et spec_CPmax 1115 (figure 11). Cette operation 
d'attribution de bande passante est effectu6e avant remission de Tinformation 
257 ou 259 (figure 3). 

25 En outre, on considere qu'un chemin qui supporte plus d'un 

nombre predetermine de transmission sortante en mode non connecte n'est 
pas disponible pour une transmission en mode non connecte supplementaire. 

Les evenements qui peuvent influencer {'attribution de bande 
passante a une transmission en mode connect6 sont de deux types : 

30 - ceux qui concement le mode connecte, Tetablissement ou la 

fermeture d'une connexion, et qui influent sur la bande passante qui lui est 
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reservee, et, par consequent, sur le nombre de paquets a emettre en mode non 
connecte mais aussi sur la taille de ces paquets. et 

- ceux qui concernent le mode non connecte, le debut ou la fin 
d'une transmission, et qui influent sur le nombre de paquets a emettre en mode 
5 non connecte. 

Pour la gestion de la table de charge illustree en figure 10, la 
charge d'un chemin est determinee par la charge du lien le moins disponible, en 
prenant en compte. pour la charge d'un lien, la somme des charges des 
chemins qui le traversent. 

10 Les chemins sortants utilises sont etablis par un moyen de 

routage de type connu. 

On observe ici que chaque noeud du reseau controle le flux qu'il 
genere et que Tinformation permettant de controler ces flux est etablie a partir 
de la table de charge qui est partagee entre les differents noeuds, chaque 
15 noeud conservant cette information sous forme d'un tableau tel que celui illustre 
en figure 1 1 . 

Les niveaux de priorite des messages sont etablis par le moyen 
de traitement a partir du sen/ice requis. 

En figure 1 1 . on observe un tableau 1 1 00, comportant trols lignes 
20 1101, 1102 et 1103, chacune des lignes comportant des specifications de 
canaux virtuels 1 105 a 1 1 10. 

On rappelle ici que chaque canal virtuel est une entite logique 
associee a une communication entre deux applications mises en oeuvre par 
deux moyens de traitements associes a deux moyens de communication. 

25 Dans le tableau de la figure 1 1 , on a choisi de repr6senter deux 

canaux virtuels pour chaque niveau de priorite, pour des raisons de clart6. 
Cependant, pour chaque niveau de priorite, le nombre de canaux virtuels peut 
varier entre zero a un nombre predetermine, 

Chacune de ces specifications comporte : 
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- une information representative de la taille "spec_L" 1111 des 
paquets associes au canal ; 

- une infornnation representative du nombre de paquets a emettre 
''spec_CP" 1112 durant Tintervalie de temps primaire considere ; 

- une information representative de la duree "spec_CT' 1113 de 
rintervalle de temps primaire considere : 

- une information representative du niveau de priorite (haut, 
moyen ou bas) "spec jor/o" 1114 associe au canal ; 

- une information "dyn_CP' 1117 representative du nombre de 
paquets reellement emis sur le canal virtuel. pendant rintervalle de temps 
primaire considere ; 

- une information "dyn_CT 1118 representative du nombre 
d'intervalles de temps secondaires ecoules pendant rintervalle de temps 
primaire consid6re ; et 

- une information ''VC_state" 1119 representative de I'etat dans 
lequel se trouve le canal virtuel. "//fare", "acf/T ou ''endormP' (voir figure 12) ; et 

- une information "references'" 1120 representative des positions 
(ou references), en memoire. des donnees utilisateur a transmettre. 

En outre, les specifications du niveau de priorite basse 

comportent : 

- une information ''specjCPmirf' 1115 representative de la valeur 
minimale du nombre de paquets a 6mettre ''specJDP" 1112 - une information 
''spec_CPmak" 1116 representative de la valeur maximale du nombre de 
paquets S emettre "spec_CP' 1112 , ceci afin de permettre de diminuer la 
valeur de ''spec_CR' 1112 au cours de reparation 1221 ou de Taugmenter au 
cours de rop§ration 1215, dans la limite de ces bornes spec_CPmin 1115 et 
specjCPmax 1116, 

Enfin, chaque ligne, ou niveau de priorite, est affectee d'une 
information "prio_state'' 1120 representative de retat dans lequel se trouve 
Tensemble des canaux virtuels du niveau de priorite considere : lorsqu'au 
niveau de priorite considere ne se trouve aucun canal, le niveau de priorite est 
"libre'\ lorsque tous les canaux du niveau de priorite sont dans un etat 
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"endormP', le niveau de priority est lui-m§me dans un 6tat "endormr, et dans las 
autres cas, le niveau de priorite est "actif. 

La table de specifications et de priorites 1100 est constituee en 

plagant : 

5 - en premiere ligne 1101 (niveau de priorite "haut") tous les 

canaux virtuels affectes a des transmissions en mode connecte. ou "temps reel 
deterministe" (en anglais "predictive real time") ; 

- en deuxieme ligne 1102 (niveau de priorite "moyen") tous les 
canaux virtuels affect6s a des transmissions en mode connecte temps r6el 

10 garanti (connu sous le nom de temps reel garanti, ou , en anglais, "guaranted 
real time") ; 

- en troisieme ligne 1103 (niveau de priority "haut") tous les 
canaux virtuels affect6s a des transmissions en mode non connects (connu 
sous les noms de "asynchrone" et "elastique". ou . en anglais "elastic"). 

15 Ainsi, tous les noeuds disposent d'une table de priorite concernant 

le trafic qu'il peut gen6rer, et chacun s'occupe des messages dont il est la 
source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie 
"trafic sortant"). 

On observe ici que les parametres de transmission sont 
20 determines par le moyen de contrSle de charge a partir du contenu de la table 
de charge. Par consequent, les parametres de transmission associ^s aux 
canaux virtuels de haute et moyenne priorite 1101 et 1102 sont calculus ^ partir 
d'une connaissance, a priori, sur tout le trafic connecte alors que les 
parametres de transmission associes aux canaux virtuels de faible priority 1103 
25 sont estimes a partir d'une connaissance limitee au trafic non-connecte sortant 
du noeud consider^. 

La figure 12 repr6sente un organigramme de fonctionnement 
d'6mission en modes connects et non connecte d'un moyen de communication 
tel qu'lllustre en figure 2. Get organigramme est mis en oeuvre par ['unite 
30 centrale 206 (figure 2). 
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Le principe du fonctionnement utilise est que I'ordre d'emission 
des paquets est base sur le remplissage d'un intervalle de temps primaire IT-P, 
comprenant des intervalles de temps secondaires IT-S. 

A la suite de {'operation d'initialisation 1201 par remise k zero de 
toutes les variables, un test 1202 determine si un intervalle de temps 
secondaire s'est ecoule. le debut d'un intervalle de temps secondaire etant 
determine a partir de Thorloge temps reel 235. Lorsque le resultat du test 1202 
est positif, au cours d'une operation 1203, 1'unite centrals 206 se place en debut 
de la table de specifications et de priorites (figure 1 1 ). 

Ensuite. au cours d'une op6ration 1204, rinformation "dyn__CT 
1 1 18 du canal virtual considere est d6cr§mentee. Puis, au cours d'un test 1205, 
Tunite centrale 206 determine si la valeur de rinformation '*dyn_CT 1118 du 
canal virtuel consid6re est egale a zero, ou non. Lorsque le resultat du test 
1205 est positif, c'est-a-dire a la fin d'un intervalle de temps primaire. au cours 
d'un test 1220, runit6 centrale 206 determine si la valeur de I'infomriation 
"dyn__CP' 1117 est 6gale d zero, ou non. Le test 1220 correspond done a 
chaque debut d'un nouvel intervalle de temps primaire. 

Lorsque le resultat du test 1220 est negatif, au cours d'une 
operation 1221, 1'unit^ centrale 206 gere les priorit6s de la maniere suivante : 

- pour le trafic detemiiniste, priorite haute, les paquets non 
transmis durant Tintervalle de temps requis, dent le nombre est egale a la 
valeur de valeur "dyn_CR' 1117, sont supprimes (perte de paquets) puis, la 
valeur "dyn^CP" 1 1 17 est mise a zero , et 

- pour le trafic garanti, priorite moyenne. les paquets non transmis 
durant Tintervalle de temps sont conserves et ''dyn_CR' 1117 conserve sa 
valeur, et 

- pour le trafic elastique, priority basse, la bande passante est 
r6dulte, par decrementation de la valeur ''spec^CR' 1112 dans la limlte des 
bornes autoris6es. 

A la suite de reparation 1221 ou lorsque le resultat du test 1220 
est positif, une operation 1206 est effectu§e. 
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Au cours de Toperation 1206. les specifications et parametres de 
transmission sont mis a jour (voir figure 11): 

- les informations 1111 a1113et 1115a 1116 sont mises a jour a 
la fin de chaque intervalle de temps primaire, en fonction des changements 

5 d'etat de la table de charge determine par le moyen de controle de charge, 

- la valeur de {'information "dyn^CP" 1117 est incrementee de la 
valeurde rinformation "spec_CP' 1112. 

- la valeur de rinformation "dyn_CT 1118 est incrementee de la 
valeurde rinformation *'spec_CT 1113, 

10 - la valeur de rinformation "\/C_sfate" 1119 passe de r6tat 

''endormr a I'etat "acf/f 

A la suite de {'operation 1206 ou lorsque le resultat du test 1205 
est negatif, une operation 1207 consiste, pour I'unite centrale 206, a considerer 
le canal virtue! suivant dans la table de specifications et de priorites. 

15 Ensuite. le test 1208 determine si la fin de la table de 

specifications et de priorites a ete depassee, ou non. Lorsque le resultat du test 
1208 est negatif. les operations 1204 a 1207 sont reiterees. Lorsque le resultat 
du test 1208 est positif, c'est-a-dire lorsqu'un intervalle de temps secondaire est 
acheve, un test 1209 determine si la liste des canaux virtuels de niveau de 

20 priorite "hauf possede une information d'6tat "prio_state" 1120 a la valeur 
"acf/r ou non. Lorsque le resultat du test 1209 est positif, au cours d'une 
operation 1210, {'unite centrale 206 precede a remission du paquet dont !e 
remplissage est effectue a partir du champ reference 1120. qui indique {a 
position memoire des prochaines donnees a emettre, en mode connects temps 

25 reei d6terminlste et procede a la mise a jour des specifications du canal virtue! 
permettant I'emission du paquet consider^ : 

- I'information "dyn_CP' 1 1 17 est d6cr6ment6e, 

- si {'information '*dyn_CP' 1117 est egale § zero, la valeur de 
I'information "VC_state'' 1119 prend la valeur "endormP' et le prochain canal 

30 virtuel du meme niveau de priorite est consid6r§ et, s'il n'y a aucun autre cana! 
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virtuel de meme niveau de priorite, le niveau de priorite voit son information 
''prio__state" 1 120 prendre la valeur "endormr, 

L'emission du paquet ne se termine que lorsque le prochain noeud 
intermediaire a acquitte le controle de flux qu'il a oper§ sur les donnees dudit 
paquet, tel que cela est decrit dans la norme IEEE-1355 et im*plennent6 par les 
composants ST-C101 213 ou 216 et ST-C104 209. 

On remarque ainsi que les conflits d'acces aux ressources de 
transmission (les liens de communications) sont detectes par le protocole de 
transmission de paquets, par exemple conforme a la norme IEEE-1355. 
Uinvention permet done de limiter les effets de ces conflits d'acces pour 
equitablement r6partir I'acces aux ressources entre les diff6rents noeuds du 
reseau, tout en garantissant une qualite de service specifiee par le service 
requis. 

Lorsque le resultat du test 1209 est negatif, un test 1211 
determine si la liste des canaux virtuels de niveau de priorite "moyen" possede 
une information d'etat ""prio^state" 1120 a la valeur "acf/f ou non. Lorsque le 
resultat du test 1211 est positif. au cours d'une operation 1212. I'unite centrale 
206 procede a remission d'un paquet en mode connecte temps reel garanti et 
precede S la mise a jour des specifications du canal virtuel permettant 
remission du paquet consider^ : 

- rinfonmation "dyn__CP' 1 1 17 est d6crementee. 

- si rinformation "dyn_CP" 1117 est egale ^ zero, la valeur de 
rinformation "\/C__sfafe" 1119 prend la valeur "endormr et le prochain canal 
virtuel du meme niveau de priority est considere et, s'il n'y a aucun autre canal 
virtuel de m§me niveau de priorite, le niveau de priority voit son infomiation 
''prio__state" 1 120 prendre la valeur "endormf\ 

Lorsque le r6sultat du test 1211 est n6gatif, un test 1213 
determine si la liste des canaux virtuels de niveau de priorite "bas" poss6de une 
information d'6tat *'prio_state" 1 120 ^ la valeur "acf/r ou non. Lorsque le r6sultat 
du test 1213 est positif, au cours d'une operation 1214. I'unite centrale 206 
procede ^ remission d'un paquet en mode non connects et procede ^ la mise ^ 
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jour des specifications du canal virtuel permettant remission du paquet 
considere : 

- information "dyn_CP* 1 117 est decrementee. 

- si I'information "^dynJDR" 1117 est egale a zero, la valeur de 
5 rinformation ''VC__state'' 1119 prend la valeur "endormi'" et le prochain canal 

virtuel du meme niveau de priorite est considere et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite. le niveau de priorite volt son information 
"prio_state" 1120 prendre la valeur "endo/m/". 

Lorsque le resultat du test 1213 est negatif. au cours d'une 
10 operation 1215. Tunite centrale precede a I'analyse de la charge effective du 
r§seau. A cet effet, runit6 centrale 206 comptabilise les periodes d'inactivite du 
moyen de communication, pour ajuster le nombre de paquets a emettre par 
canal virtuel, pour le trafic de priorite basse (c'est-^-dire en mode non 
connecte). 

15 En fonction du nombre d'inten/alles de temps secondaires non 

utilises pour la transmission effective de paquets. la bande passante est accrue, 
par incrementation de la valeur "spec_CR' 1112 dans la limite des bornes 
autorisees. 

Puis, le moyen de communication cesse ses emissions jusqu'a ce 
20 que le resultat du test 1202 devienne positif. 

L'allocation ou la liberation d'un canal virtuel est effectu6e par 

manipulation: 

- des listes 1101 et 1102, lors de Texecution des differentes 
etapes de gestion d'une connexion illustree en figure 4. 
25 - de la liste 1103, lors de la reception d'un message 

""SendSyncData^req" ou ''SendAsyncData_cff\ par le moyen de 
communication, 6mis par le moyen de traitement, jusqu'a transmission 
complete du message. 

Ainsi, le moyen de controle de charge tient compte de la charge 
30 effective sur le r6seau pour r6partir les droits d'acces entre les diff6rents 
niveaux de priority. 
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La figure 13 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour Tetablissement d'une connexion, 
ce qui correspond, en figure 4. a I'operation 302. 

Le moyen de communication prend en compte la description du 
service requis etabli par Tappiication ou le peripherique qui emet le message, 
au cours d'une operation 1302. 

Puis, le moyen de communication effectue le choix du canal virtuel 
et du chemin le plus disponible, au cours de Toperation 1304, en faisant usage 
de la table de routage. 

Au cours d'un test 1305, le moyen de communication du noeud 
source determine si un chemin a ete choisi au cours de Toperation 1304 ou 
non. 

Lorsque le resultat du test 1305 est negatif, le moyen de 
communication revendique Tarret de la procedure de mise en place de la 
connexion, au cours d'une operation 1306. Lorsque le resultat du test 1305 est 
positif, !e moyen de communication effectue le calcul des parametres de 
transmission, en particulier de la bande passante. de la taille des paquets 
transmis, des taux (frequences d'emission) de paquets et de priorite de la 
communication correspondant au champ 1111 a 1113 illustres en figure 11. en 
faisant usage de la table de charge, au cours d'une operation 1303. 

Puis, au cours d'une operation 1307, le moyen de communication : 

- alloue un canal virtuel en specifiant les paramfetres de 
transmission pr6cedemment calcules, et 

- fait verier la taille des paquets avec la charge du chemin ainsi 
que le taux de paquets sur ledit chemin, et 

- met a jour sa table de charge par rinterm6diaire du moyen de 

controle de charge. 

Ensuite. au cours d'une operation 1308, il revendique la poursuite 
de la mise en place de la connexion 

L'op6ration 302 est alors termin§e. 
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La figure 14 represente un organigramme de determination, par 
un noeud intermediaire ou le noeud destinataire. de disponibilite de chemin 
pour retablissement d'une connexion, ce qui correspond, en figures 5 et 6, aux 
operations 332 et 372. 

5 Le moyen de communication obtient, d*abord, la description du 

chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 251 "set-up" provenant du noeud source (operation 305), au cours 
d'une operation 1402, 

Puis, le moyen de communication verifie la disponibilite du chemin 
10 en fonction du service requis, au cours de {'operation 1404, en faisant usage de 
la table de routage. 

Au cours d'un test 1405, le moyen de communication du noeud 
considere determine si le chemin est disponible au cours de I'operation 1404 ou 
non. 

15 Lorsque le resultat du test 1405 est negatif, le moyen de 

communication revendique la procedure de mise en place de la connexion, au 
cours d'une operation 1406. Lorsque le resultat du test 1405 est positif, le 
moyen de communication effectue le calcul des parametres de transmission, en 
particulier de la bande passante. de la taille des paquets transmis, des taux 

20 (frequence d'emission) de paquet et de priorite de la communication, en faisant 
usage de la table de charge, au cours d'une operation 1403. 

Puis, au cours d'une operation 1407, le moyen de communication 
met a jour sa table de charge par Tintermediaire du moyen de controle de 
charge, ce qui revient a reserver les ressources necessaires a la connexion 
25 envisagee, puis, au cours d'une operation 1408, il poursuit la mise en place de 
la connexion. A la fin de I'une des operations 1406 ou 1408, I'operation 334 est 
terminee. 

La mise a jour de la table de charge s'accompagne d'une mise a 
jour des parametres de transmissions associ6s aux canaux virtuels existants 
30 representatifs du trafic sortant pour le noeud consid6r6, a travers la valeur des 
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champs 1111 a 1113 pour le trafic connecte et 1111, 1113, 1115. 1116 pour le 
trafic non connecte. 

La figure 15 represente un organigramme de determination, par 
un noeud voisin, de disponibilite de chemin pour Tetablissement d'une 
connexion, ce qui correspond, en figure 7, aux operations 413. 

Le moyen de communication obtient, d'abord. la description du 
chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 253 "LinkTabLoacT' provenant du noeud source (operation 313). au 
cours d'une operation 1502. 

Ensuite. le moyen de communication effectue le choix des 
parametres de transmission, en particulier de la bande passante. de la taille des 
paquets transmis, des taux de paquet et de priorite de la communication, en 
faisant usage de la table de charge, au cours d'une operation 1503. Puis, au 
cours d'une operation 1504. le moyen de communication met a jour sa table de 
charge. A la fin de Toperation 1504, le fonctionnement de mise en place de la 
connexion, par le noeud voisin, est termine. 
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REVENDICATIONS 

1. Procede de communication sur un reseau (800) comportant des 
dispositifs de communication (801 a 809), chaque dispositif de communication 
etant adapte a determiner, pour cliaque information qu'il a a transmettre, le 
5 chemin a lui faire suivre sur le reseau, et un mode de transmission, connecte ou 
non, caracterise en ce qu'il comporte : 

- pour chaque dispositif de communication qui doit effectuer une 
transmission en mode connecte. une operation d'information (313) au cours de 
laquelle ledit dispositif de communication diffuse, a destination de tous les 

10 autres dispositifs de communication du reseau, une information (253) 
representative de la bande passante necessaire pour ladite transmission en 
mode connecte. et 

- une operation d'attribution de bande passante (1221), au cours de 
laquelle on attribue, d'une part, aux transmissions en mode connecte, la bande 

15 passante qui leur est necessaire et, d'autre part, tout ou partie de la bande 
passante disponible a chaque transmission a effectuer en mode non connecte. 



2. Procede de communication selon la revendication 1 . caracterise 
en ce qu'il comporte, pour un etablissement de connexion : 

20 - effectuee par le dispositif de communication source (801 ) destine a 

transmettre de Tinfomiation sur ledit chemin, une operation de transmission (305), 
a destination de chaque dispositif de communication place sur ledit chemin, 
appele "intermediaire" (803, 804), d'une information (251) representative de la 
bande passante necessaire pour ladite connexion, et 

25 - effectu6e par chaque dispositif de communication interm6diaire sur 

ledit chemin. une operation de determination de disponibilite (1402, 1404) du lien 
menant au dispositif de communication suivant sur ledit chemin et, en cas 
d'indisponibilit6, une operation de transmission (333) a destination du dispositif de 
communication source, d'une information representative de rindisponibilite dudit 

30 chemin. 



0 
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3. Proced6 de communication selon Tune quelconque des 
revendications 1 ou 2, caracterise en ce qu'il comporte. pour chaque transmission 
d'information. une operation de controle de flux effectuee par chacun des 
dispositifs de communication intermediaires du chemin suivi par fadite information. 

4. Procede de communication selon la revendication 3. caracterise 
en ce que Toperation de controle de flux effectuee par chaque dispositif de 
communication intennediaire est effectuee conformement a la norme IEEE 1355. 

5. Procede de communication selon Tune quelconque des 
revendications 1 a 4, caracterise en ce qu'il comporte : 

- pour chaque dispositif de communication du reseau, a la suite de 
chaque operation d'information, une operation de determination de la bande 
passante (1303, 1403, 1503) disponible sur chaque lien, en prenant en compte 
esdites informations, et 

- pour chaque dispositif de communication dit "source" qui doit 
effectuer une transmission en mode non connecte a destination d'un dispositif 
de communication destinataire : 

• une operation de determination de disponibilite de chemin 
pour une transmission en mode non connecte, au cours 
de laquelle on determine si au moins une chemin allant 
dudit dispositif de communication source audit dispositif 
de communication destinataire est au moins partiellement 
disponible pour ladite transmission, 

• et, dans raffirmative, une operation de transmission sur 
ledit chemin, en mode non connecte. 

6. Proc6de de communication selon Tune quelconque des 
revendications 1^5, caract6ris6 en ce qu'il comporte une operation de la 
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transmission d'information (254. 257, 259) prenant en compte plusieurs niveaux 
de priorite. 

7. Precede de communication selon la revendication 6. caracterise 
5 en ce qu'un niveau de priorite est affecte a la transmissioh en mode non 

connecte. 

8. Procede de communication selon Tune quelconque des 
revendications 6 ou 7. caracterise en ce que, au cours de Toperation 

10 d'attribution de bande passante (1221). la bande passante associee au niveau 
de priorite correspondant au mode non connecte varie en fonction d'une duree 
n'ayant donne lieu a aucune transmission. 

9. Procede de communication selon la revendication 8, caracterise 
15 en ce que ladite dur6e est la duree separant la demiere transmission en mode 

non connecte et la prochaine transmission en mode connecte. 



10. Procede de communication selon Tune quelconque des 
revendications 6 a 9. caracterise en ce que. au cours de Toperation d'attribution 
20 de bande passante (1221). la bande passante associee au niveau de priorite 
correspondant au mode non connecte varie en fonction d'un nombre de 
paquets non transmis pendant une duree predeterminee. 



11. Procede de communication selon Tune quelconque des 
25 revendications 6 a 10. caracterise en ce que le trafic temps reel deterministe est 

transmis avec un niveau de priorite sup6rieur a celui du trafic temps r6el garanti. 

12. Procede de communication selon Tune quelconque des 
revendications 6 a 11, caracterise en ce que chaque niveau de priorit6 est 

30 associe a une liste de canaux virtuels (1105 a 1110). successivement mis en 
oeuvre. 
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13. Procede de communication selon la revendication 12, 
caracterise en ce que lesdits canaux virtuels sont associes au trafic sortant. 

5 14. Procede de communication selon Tune quelconque des 

revendications 12 ou 13, caracterise en ce qu'il comporte une operation de 
determination de parametres de transmission (1221), au cours de laquelle on 
determine une dimension de paquets transmis sur ledit reseau, ladite operation 
prenant en compte la charge sur ledit reseau. 

10 

15. Procede de communication selon Tune quelconque des 
revendications 12 ^ 14. caracteris§ en ce qu'il comporte une operation de 
determination de parametres de transmission (1221). au cours de laquelle on 
determine un nombre de paquets a emettre sur ledit reseau. ladite operation 

1 5 prenant en compte la charge sur ledit r6seau. 

16. Procede de communication selon Tune quelconque des 
revendications 12 a 15, caracterise en ce qu'il comporte une operation de 
determination de parametres de transmission (1221), au cours de laquelle on 

20 determine une duree disponible pour emettre les paquets restant a emettre sur 
ledit reseau, ladite operation prenant en compte la charge sur ledit reseau. 

17. Procede de communication selon Tune quelconque des 
revendications 14 a 16, caracterise en ce que Toperation de determination de 

25 parametres de transmission (1221) a lieu, pour cheque dispositif de 
communication, lors de I'etape d'information. 

18. Procede de communication selon Tune quelconque des 
revendications 14 S 17, caract6ris6 en ce que I'operation de determination de 

30 parametre de transmission (1221) a lieu, pour chaque dispositif de 
communication, canal virtue! par canal virtuel. 
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19. Precede de communication selon Tune quelconque des 
revendications 14 a 18, caracterise en ce que ladite operation de determination 
de parametres de transmission (1221) est effectuee lors de I'operation 
d'information (313). 

5 

20. Precede de communication selon Tune quelconque des 
revendications 6 a 19, caracterise en ce qu'il comporte une operation de 
transmission d'information de controle, au cours de laquelle chaque information 
de controle est transmise avec le plus fiaut niveau de priorite. 

10 

21. Precede de communication selon I'une quelconque des 
revendications 6 a 20, caracterise en ce que, pour au moins un niveau de 
priorite, rinformation non transmise durant un intervalle de temps predetermine, 
est eliminee avant transmission. 

15 

22. Precede de communication selon I'une quelconque des 
revendications 6 a 21, caracterise en ce que. pour au meins un niveau de 
priorite, rinformation non transmise durant un intervalle de temps predetermine, 
est conservee pour etre transmise durant I'inten/alle de temps suivant. 

20 

23. Precede de communication selon Tune quelconque des 
revendications 1 a 22, caracterise en ce que le trafic temps reel, deterministe ou 
garanti. est transmis en mode connecte. 

25 24. Precede de communication selon Tune quelconque des 

revendications 1 di 23, caract6ris6 en ce que le trafic elastique est transmis en 
mode non connects. 

25. Precede de communication selon Tune quelconque des 
30 revendications 1 a 24. caracterise en ce qu'il comporte, pour chaque dispositif 
de communication place sur le chemin destine a etre suivi par une transmission 




en mode connecte, una operation de verification (1404). au cours de laquelle. 
on v6rifie que la bande passante necessaire a ladite transmission est disponible 
sur ledit chemin. 

5 26. Procede de communication selon Tune quelconque des 

revendications 1 a 25, caracterise en ce que. pour le trafic deterministe. 
{'information non transmise durant un intervalle de temps predetermine, est 
eliminee avant transmission. 

10 27. Procede de communication selon Tune quelconque des 

revendications 1 a 26, caracterise en ce que, pour le trafic garanti, I'information 
non transmise durant un inter/alle de temps predetermine, est conservee pour 
etre transmise durant I'intervalle de temps suivant. 

15 28. Proc6de selon Tune quelconque des revendications 1 a 27, 

caracterise en ce que chaque dispositif de communication effectue chaque 
transmission d"information par commutation de paquet. 

29. Procede de communication selon I'une quelconque des 
20 revendications 1 a 28, caracterise en ce qu'il comporte, pour I'etablissement d'une 
connexion : 

A/ effectu6es par un dispositif de communication source 
d'information a transmettre en mode connecte : 

- une operation de determination de besoin de bande passante pour 
25 la transmission de ladite information en mode connecte, 

- une operation de determination d'un 6ventuel chemin disponible 
pour ladite transmission, en fonction d'informations conserv6es dans une table de 
charge de chaque lien du reseau, et 

- lorsqu'un chemin disponible est determine : 
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• une operation d'emission d'une information representative 
dudit besoin de bands passante a destination du dispositif 
de communication suivant sur ledit chemin. et 

• une operation de mise a jour de ladite table de charge des 
liens du reseau, 

- une operation de diffusion a destination d*au moins tous les 
dispositifs de communication en dehors du chemin, d'une information 
representative dudit besoin de bande passante, 

B/ effectuees par chaque dispositif de communication intermediaire 
sur ledit chemin : 

- une operation de determination de disponibilite dudit chemin, pour 
ladite communication, en fonction d'informations consen/ees dans une table de 
charge de chaque lien du reseau. et 

- lorsque le chemin est disponible : 

• une operation d'emission d*une information representative 
dudit besoin de bande passante. au dispositif de 
communication suivant sur le chemin. et 

• une operation de mise a jour d'une table de charge des 
liens du reseau, 

CI effectuee par chaque dispositif de communication en dehors 
dudit chemin : 

- une operation de mise a jour d'une table de charge des liens du 

reseau. 

30. Proc6de de communication selon Tune quelconque des 
revendications 1 29, entre des dispositifs de communication susceptibles, de 
determiner, chacun. pour chaque information qu'il a a transmettre, un chemin ^ 
lui faire suivre, caracterise en ce qu'il comporte : 

- effectuee par chaque dispositif de communication dit "source", 
qui a besoin d'une connexion associee a un chemin, pour effectuer une 
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transmission d'information a destination d'un dispositif de communication 
destinataire, une operation de demands de connexion, au cours de laquelle, le 
dispositif de communication source §met, a destination de chaque dispositif de 
communication dudit chemin. une demande d'etablissement de connexion, 

- lorsque I'^tablissement de ladite connexion est possible, 
effectuee par au moins le dispositif de communication destinataire, une 
operation d'emission a destination du dispositif de communication source d'une 
acceptation de connexion, 

- effectuee par le dispositif de communication source, une 
operation de diffusion, a tous les dispositifs de communication du reseau, d'une 
information representative de Tetablissement de la connexion. 

- effectu6e par chaque dispositif de communication dudit chemin, 
a reception de ladite information representative d'etablissement de connexion, 
une operation de confimnation d'etablissement de ladite connexion, et 

- effectuee par chaque dispositif de communication en dehors 
dudit chemin, a reception de ladite information representative d'etablissement 
de connexion, une operation de mise en memoire d'une information 
representative de ladite connexion. 

31. Dispositif de communication sur un reseau comportant des 
dispositifs de communication, chaque dispositif de communication etant adapte 
a determiner, pour chaque information qu'il a a transmettre, un chemin a lui 
faire suivre sur le reseau et un mode de transmission, connecte, ou non, 
caracterise en ce qu'il comporte : 

- un moyen d'information adapte. pour chaque transmission en 
mode connects, a diffuser, a destination de tous les autres dispositifs de 
communication du reseau, une information representative de la bands passante 
necessaire pour ladite transmission en mode connecte, et 

- un moyen d'attribution de bande passante. adapte a attribuer, 
d'une part, aux transmissions en mode connecte, la bande passante qui leur est 
n6cessaire et, d'autre part, tout ou partie de la bande passante disponible ^ 
chaque transmission § effectuer en mode non connecte. 




32, Dispositif de communication selon la revendication 31, 
caracterise en ce que : 

- le moyen d'information est adapte, pour un etablissement de 
5 connexion, a transmettre, a destination de chaque dispositif de communication 

place sur ledit chemin, appele "intermediaire", une information representative de 
la bande passante necessaire pour ladite connexion, et 

- il comporte un moyen de determination de disponibilit6 en mode 
connecte, adapte, lorsque ledit dispositif de communication est un dispositif de 

10 communication intermediaire sur un chemin destine a etre associe a une 
connexion, a determiner la disponibilit6 du lien menant au dispositif de 
communication suivant sur ledit chemin et. en cas d'indisponibilite, ^ faire 
transmettre, a un moyen de transmission, a destination du dispositif de 
communication source, une information representative de rindisponibilit6 dudit 

1 5 chemin. 

33. Dispositif de communication selon Tune quelconque des 
revendications 31 ou 32, caracterise en ce qu'il comporte, un moyen de controle 
de flux adapte, pour chaque transrhission d'information en mode non connecte 

20 pour laquelle ledit dispositif est incorpore dans un dispositif de communication 
intermediaire, a verifier la disponibilite du chemin suivi par ladite information. 

34, Dispositif de communication selon la revendication 33, 
caracterise en ce qu*il est adapte a mettre en oeuvre des procedures de 

25 communication confomnes ^ la norme IEEE 1355. 

35. Dispositif de communication selon Tune quelconque des 
revendications 31 ^ 34, caracteris6 en ce qui! comporte un moyen de 
determination de bande passante disponible adapts : 



58 



- a determiner la bande passante disponible sur chaque lien d'un 
chemin associe ^ une connexion, a reception de chaque information 
representative de bande passante en provenance d'un autre dispositif de 
communication, en prenant en compte ladite information, et 

- lorsque ledit dispositif de communication dolt effectuer une 
transmission en mode non connecte a destination d'un dispositif de 
communication destinataire, a determiner la disponibilite au moins partielle d'au 
moins un chemin allant dudit dispositif de communication source audit dispositif 
de communication destinataire pour une transmission en mode non connecte. 

36. Dispositif de communication selon Tune quelconque des 
revendications 31 a 35, caracterise en ce qu'il comporte un moyen de 
transmission d'information prenant en compte plusieurs niveaux de priorite, 

37. Dispositif de communication selon la revendication 36, 
caracterise en ce que le moyen de transmission est adapte a ce qu'un niveau 
de priorite soit affecte a la transmission en mode non connecte. 

38. Dispositif de communication selon Tune quelconque des 
revendications 36 ou 37, caracteris6 en ce que le moyen d'attribution de bande 
passante est adapt6 ^ ce que la bande passante associee au niveau de priorite 
correspondant au mode non connects varie en fonction d*une duree n'ayant 
donne lieu a aucune transmission. 

39. Dispositif de communication selon la revendication 38. 
caracterise en ce que le moyen d'attribution de bande passante est adapte a ce 
que ladite dur6e soit la dur6e separant la demiere transmission en mode non 
connects et la prochaine transmission en mode connect6. 

40. Dispositif de communication selon Tune quelconque des 
revendications 36 d 39, caract6ris6 en ce que le moyen d'attribution de bande 
passante est adapts S ce que la bande passante associ6e au niveau de priority 
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correspondant au mode non connecte varie en fonction d'un nombre de 
paquets non transmis pendant une dur6e pr6determinee. 

41. Dispositif de communication salon I'une quelconque des 
revendications 36 a 40, caracterise en ce que le moyen de transmission 
d'information est adapte a ce que le trafic temps reel deterministe soit transmis 
avec un niveau de priorite superieur a celui du trafic temps reel garanti. 

42. Dispositif de communication selon Tune quelconque des 
revendications 36 a 41, caracterise en ce que le moyen de transmission 
d'information est adapte a ce que chaque niveau de priorite soit associe a une 
liste de canaux virtuels, successivement mis en oeuvre. 

43. Dispositif de communication selon la revendication 42, 
caracterise en ce que le moyen de transmission dinformation est adapte a ce 
que lesdits canaux virtuels soient associes au trafic sortant. 

44. Dispositif de communication selon Tune quelconque des 
revendications 42 ou 43, caracterise en ce qu'il comporte un moyen de 
determination de parametres de transmission adapte a determiner une 
dimension de paquets transmis sur ledit reseau, en prenant en compte la 
charge sur ledit reseau. 

45. Dispositif de communication selon Tune quelconque des 
revendications 42 a 44, caracterise en ce qu'il comporte un moyen de 
determination de parametres de transmission adapte a determiner un nombre 
de paquets a emettre sur ledit reseau, en prenant en compte la charge sur ledit 
reseau. 

46. Dispositif de communication selon Tune quelconque des 
revendications 42 a 45. caracteris6 en ce qu'il comporte un moyen de 
determination de parametres de transmission adapte d determiner une duree 
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disponible pour emettre les paquets restant a emettre sur ledit reseau, en 
prenant en compte la charge sur ledit reseau. 

47. Dispositif de communication selon Tune quelconque des 
5 revendications 44 a 47, caracterise en ce que le moyen de determination de 

parametres de transmission est adapte a determiner lesdits parametres, canal 
virtuel par canal virtuel. 

48. Dispositif de communication selon Tune quelconque des 
10 revendications 36 a 47, caracterise en ce que le moyen de transmission est 

adapte a transmettre chaque information de controle avec le plus haut niveau 
de priorite. 

49. Dispositif de communication selon Tune quelconque des 
15 revendications 36 a 48, caracterise en ce que le moyen de transmission est 

adapte a ce que, pour au moins un niveau de priorite, Tinformation non 
transmise durant un intervalle de temps predetermine, est eliminee avant 
transmission. 

20 50. Dispositif de communication selon Tune quelconque des 

revendications 36 a 49, caracterise en ce que le moyen de transmission est 
adapte a ce que, pour au moins un niveau de priorite, Tinformation non 
transmise durant un intervalle de temps predetermine, est conservee pour etre 
transmise durant Tintervalle de temps suivant. 

25 

51. Dispositif de communication selon Tune quelconque des 
revendications 31 ^ 50, caract6ris6 en ce qu'il est adapte a ce que le trafic 
temps r§el, deterministe ou garanti, soittransmis en mode connecte. 
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52. Dispositif de communication selon Tune quelconque des 
revendications 31 a 51, caracterise en ce qu'il est adapte S ce que le trafic 
6lastique soit transmis en mode non connecte. 

5 53. Dispositif de communication selon Tune quelconque des 

revendications 31 a 52, caracterise en ce que chaque dispositif de 
communication place sur le chemin destine a etre suivi par une transmission en 
mode connecte, comporte un moyen de verification adapte a verifier que la 
bande passante necessaire a ladite transmission est disponible sur ledit 
10 chemin. 

54. Dispositif de communication selon Tune quelconque des 
revendications 31 a 53. caracterise en ce qu'il comporte un moyen de 
transmission adapte a eliminer I'lnformation non transmise durant un intervalle 
15 de temps predetermine, pour le trafic deterministe. 



55. Dispositif de communication selon Tune quelconque des 
revendications 31 a 54, caracterise en ce qu'il comporte un moyen de 
transmission adapte a conserver pour une transmission ulterieure I'information 
20 non transmise durant un inten/alle de temps predetermine, pour le trafic garanti. 



56. Dispositif selon Tune quelconque des revendications 31 a 55, 
caracterise en ce que chaque dispositif de communication est adapte a mettre 
en oeuvre un protocole de transmission d'information par commutation de 
25 paquet. 



57. Dispositif de communication selon Tune quelconque des 
revendications 31 ^56, caract6ris6 en ce que : 

- il effectue des transmissions de donnees selon diff6rentes 
30 classes de service pour vehiculer un trafic en mode connecte, un trafic en mode 

non connecte et un trafic de controle, 

- il comporte : 
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o un moyen d'etablissement d'une duree de base, 
o une liste de transmissions en nnode connecte. et 
o une liste de transmissions en mode non connecte. 

58. Dispositif de communication selon la revendication 57. 
caract6rise en ce qu'il comporte : 

- un moyen de determination de temps libra dans ladite periode de 
base apres sequencement de toutes las transmissions, adapte a organiser 
toutes les autres transmissions, et 

- un moyen de regulation adapte a reguler la bande passante 
disponible pour les transmissions en mode non connecte. 

59. Dispositif de communication selon Tune quelconque des 
revendications 57 ou 58, caracterise en ce que ledit moyen de regulation est 
adapts : 

- a diminuer la bande passante ailouee aux transmissions en 
mode non connecte. lorsque le temps libre est negatif, et 

- a augmenter la bande passante ailouee aux transmissions en 
mode non connects, lorsque le temps libre est positif. 

60. Dispositif de communication selon Tune quelconque des 
revendications 31 a 59, caracterise en ce que : 

- il comporte une memoire adaptee a conserver une table de charge 
contenant des infomnations relatives d la charge de chaque lien du reseau, et 

- il est adapte, pour Tetablissement d'une connexion : 
pour la transmission d'information en mode connecte : 

- a determiner un besoin de bande passante pour la transmission de 
ladite information en mode connecte, 

- k determiner un eventuel chemin disponible pour ladite 
transmission, en fonction d'informations consen/ees dans ladite table de charge, 

et lorsqu'un chemin disponible est determine. 
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- a faire emettre, au moyen de transmission, une infomnation 
representative dudit besoin de bande passante, a destination du dispositif de 
communication suivant sur ledit chemin, 

- a mettre a jour ladite table de charge, 

5 - a faire diffuser, par le moyen de transmission, a destination d'au 

moins tous les dispositifs de communication en dehors du chemin, une 
information representative dudit besoin de bande passante. 

61. Dispositif de communication selon Tune quelconque des 
10 revendications 31 a 60, sur un reseau comportant des dispositifs de 

communication susceptibles, cliacun, de determiner le chemin a faire suivre a 
chaque information qu'il a a emettre, caracterise en ce qu'il est adapte, lorsqu'il 
a besoin d'une connexion associee a un chemin, pour effectuer une 
transmission d'information a destination d'un dispositif de communication 
15 destinataire : 

- a faire emettre, par le moyen de transmission, a destination de 
chaque dispositif de communication dudit chemin, un message de demande 
d'etablissement de connexion, at 

- a reception d'un message d'acceptation de connexion en 
20 provenance du dispositif de communication destinataire, a faire diffuser, par 

ledit moyen de transmission, a tous les dispositifs de communication du r6seau, 
un message d'information d'etablissement de la connexion. 

62. Ordinateur, caracterise en ce qu'il comporte un dispositif de 
25 communication selon Tune quelconque des revendications 31 a 61. 

63. Camera, caracterisee en ce qu'elle comporte un dispositif de 
communication selon Tune quelconque des revendications 31 a 61, 

30 64. Telecopieur, caracterise en ce qu'il comporte un dispositif de 

communication selon Tune quelconque des revendications 31 a 61. 
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65. Appareil photographique. caracterise en ce qu'il comporte un 
dispositif de communication selon Tune quelconque des revendications 31 a 61. 

66. T6leviseur, caracterise en ce qu'il comporte un dispositif de 
5 communication selon Tune quelconque des revendications 31 a- 61 . 

67. Imprimante. caracterisee en ce qu'elle comporte un dispositif 
de communication selon Tune quelconque des revendications 31 a 61. 

10 68. Scanner, caracterise en ce qu'il comporte un dispositif de 

communication selon I'une quelconque des revendications 31 a 61 . 

69. Lecteur audio/video, caracterise en ce qu'il comporte un 
dispositif de communication selon I'une quelconque des revendications 31 a 61. 

15 
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disponible pour emettre les paquets restant S 6mettre sur ledit r6seau, en 
prenant en compte la charge sur ledit r6seau. 

47. Dispositif de communication selon Tune quelconque des 
5 revendications 44 a 46, caract§ris6 en ce que le moyen de determination de 

parametres de transmission est adapts a determiner lesdits parametres, canal 
virtue! par canal virtue!. 

48. Dispositif de communication selon I'une quelconque des 
10 revendications 36 a 47, caract6ris6 en ce que le moyen de transmission est 

adapt6 S transmettre chaque information de controle avec le plus haut niveau 
de priorite. 

49. Dispositif de communication selon Tune quelconque des 
15 revendications 36 S 48, caracteris6 en ce que le moyen de transmission est 

adapts a ce que, pour au moins un niveau de priorite, I'information non 
transmise durant un intervaile de temps pr6d6termin6, est elimin6e avant 
transmission. 

20 50. Dispositif de communication selon Tune quelconque des 

revendications 36 S 49. caracterise en ce que le moyen de transmission est 
adapts a ce que, pour au moins un niveau de priorite, Tinformation non 
transmise durant un intervaile de temps predetermine, est conservee pour §tre 
transmise durant rinten^alle de temps suivant. 

25 

51. Dispositif de communication selon Tune quelconque des 
revendications 31 ^ 50, caract^ris^ en ce qu'il est adapte a ce que le trafic 
temps r6el, deterministe ou garanti, soittransmis en mode connects. 
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52. Dispositif de communication selon Tune quelconque des 
revendications 31 S 51, caracterise en ce qu'il est adapt6 h ce que le trafic 
elastique soit transmis en mode non connecte. 

5 53. Dispositif de communication selon Tune quelconque des 

revendications 31 ^ 52, caracterise en ce que chaque dispositif de 
communication place sur le chemin destin6 a etre suivl par une transmission en 
mode connecte, comporte un moyen de verification adapte k verifier que la 
bande passante n^cessaire k ladite transmission est disponible sur tedit 
10 chemin. 



54. Dispositif de communication selon I'une quelconque des 
revendications 31 a 53, caracteris6 en ce qu'il comporte un moyen de 
transmission adapte k eiiminer I'information non transmise durant un intervalle 
15 de temps predetermine, pour le trafic d6terministe. 



55. Dispositif de communication selon Tune quelconque des 
revendications 31 a 54, caracterise en ce qu'il comporte un moyen de 
transmission adapt6 a conserver pour une transmission ulterieure Tinformation 

20 non transmise durant un intervalle de temps predetermine, pour le trafic garanti. 

56. Dispositif selon Tune quelconque des revendications 31 k 55, 
caracterise en ce que chaque dispositif de communication est adapte a mettre 
en oeuvre un protocole de transmission d'information par commutation de 

25 paquet. 

57. Dispositif de communication selon Tune quelconque des 
revendications 31 ^ 56, caracterise en ce qu'il comporte : 

- un moyen de determination de temps fibre dans ladite periode de 
30 base apres s6quencement de toutes les transmissions, adapte ^ organiser 
toutes les autres transmissions, et 
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- un moyen de regulation adapte a reguler la bande passante 
disponible pour les transmissions en mode non connecte. 

58. Dispositif de communication selon Tune quelconque des 
5 revendications 56 ou 57, caraot^ris^ en ce que ledit moyen de regulation est 

adapts : 

- ^ diminuer la bande passante allouee aux transmissions en 
mode non connects, lorsque le temps libre est n6gatif, et 

- d augmenter la bande passante allouSe aux transmissions en 
10 mode non connects, lorsque le temps libre est positif. 

59. Dispositif de communication selon Tune quelconque des 
revendications 31 a 58, caractSrisS en ce que : 

- il comporte une memoire adaptSe k conserver une table de charge 
15 contenant des informations relatives a la charge de chaque lien du rSseau, et 

- il est adapte, pour Tetablissement d'une connexion : 
pour la transmission d'information en mode connects : 

- ^ dSterminer un besoin de bande passante pour la transmission de 
ladite information en mode connecte, 

20 - a dSterminer un Sventuel chemin disponible pour ladite 

transmission, en fonction d'informations conservSes dans ladite table de charge, 

et lorsqu'un chemin disponible est determine, 

- ^ faire Smettre, au moyen de transmission, une Infomnation 
reprSsentative dudit besoin de bande passante, S destination du dispositif de 

25 communication suivant sur ledit chemin, 

- d mettre a jour ladite table de charge, 

- d faire diffuser, par le moyen de transmission, k destination d'au 
moins tous les dispositifs de communication en dehors du chemin, une 
information reprSsentative dudit besoin de bande passante. 

30 




60. Disposltif de cxunmunication selon Tune quelconque des 
revendications 31 ^ 59, sur un r6seau comportant des dispositifs de 
communication susceptibles, chacun, de detemniner le chemin d faire suivre ^ 
chaque infomnation qu'il a § 6mettre, caract6ris§ en ce qu'il est adapts, lorsquMI 

5 a besoin d'une connexion associ§e d un chemin, pour effectuer une 
transmission d'Information a destination d'un dispositif de communication 
destinataire : 

- d faire emettre, par le moyen de transmission, a destination de 
chaque dispositif de communication dudit chemin, un message de demande 

1 0 d'6tablissement de connexion, et 

- a reception d'un message d'acceptation de connexion en 
provenance du dispositif de communication destinataire, a faire diffuser, par 
ledit moyen de transmission, a tous les dispositifs de communication du r6seau, 
un message d'Information d'etabllssement de la connexion. 

15 

61 . Ordlnateur, caracterls6 en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 31 d 60. 

62. Camera, caract6ris6e en ce qu'elle comporte un dispositif de 
20 communication selon Tune quelconque des revendications 31 S 60. 



63. Telecopleur, caracteris^ en ce qu'il comporte un dispositif de 
communication selon I'une quelconque des revendications 31 S 60 



25 64. Apparell photographlque, caract6ris6 en ce qu'il comporte un 

dispositif de communication selon I'une quelconque des revendications 31 d 60. 

65. T6l§viseur, caract6ris6 en ce qu'il comporte un dispositif de 
communication selon I'une quelconque des revendications 31 S 60. 

30 

66. Imprimante, caract^ris§e en ce qu'elle comporte un dispositif 
de communication selon I'une quelconque des revendications 31 d 60. 



Iks 
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67. Scanner, caract^risS en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 31 d 60. 

5 68. Lecteur audio/video. caract§ris6 en ce qu'il comporte un 

dispositif de communication selon Tune quelconque des revendications 31 k 60. 
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